I would make the example for you but I’m tied up at least the next week. If you nobody else can help you ping me again and I can give it a shot.
I’ll be gone for the next week anyhow and working on documentation after that, so there’s no huge rush.
@muratmaga tells me this issue is bottleneck for SlicerMorph, so it would be great to get to the bottom of it. Unfortunately depth peeling seems to be touching low level in OpenGL driver code that is rarely used and different across platforms.
Here’s a script that uses pure vtk python to do volume rendering with cropping and depth peeling that should be very similar to what Slicer does. This renders script fine for me on mac and one linux machine but has some artifacts on a different linux machine (no VirtualGL involved). It would be good to know if this can be used to track down the VirtualGL issue at the VTK level.
I believe that EGLBE: Test/Fix issues with draw buffer state · VirtualGL/virtualgl@adabbd9 · GitHub accidentally fixed this. I can no longer reproduce the issue after that commit.
2 Likes
That’s great news, thanks for reporting back 
This is great. What would we need to change in this Slicer docker image for Jupyter/Lab to get this fix?
@lassoan Unless you are using VirtualGL (and it doesn’t appear that you are), this issue is not relevant to you.
Could you help with for switching to using VirtualGL? The dockerfile was created by someone else several years ago and I’m not sure what and how would need to be changed.
@lassoan Using VirtualGL isn’t just a matter of changing the Dockerfile. You would need additional configuration on the host machine. I do such work as a paid consultant, and if you are interested in hiring me, contact me off-list: VirtualGL | About / Contact.
1 Like