On Jun 17, 2009, at 11:32, Valerie Coffman wrote:
Jeremy Huddleston wrote:
This is really better suited for xquartz-dev, so moving there...
The result for Valerie's vtk scripts is the same as with 2.3.3.2, with one exception: The "correct" vtk window from imagepluspoly.py now renders extremely slowly, it follows mouse movements with about 1 frame per second.
Whoa. it must be triggering something bad in our old libGL to be seeing such low performance.
There were some changes in 2.3.2, so I'd also try 2.3.1 and start stepping back towards 2.2.3 (which was pretty much what was in OSX 10.5.5) to see if any of those make a difference.
I had noticed the same low performance with 2.3.2 but didn't think to mention it earlier.
With 2.3.3.2 it is fluid, as are (with both 2.3.2 and 2.3.3.2) the "wrong" windows using gtk that do not show the volume object.
My configuration is similar to Valerie's, same Mbook pro, same GeForce 8600M GT graphics card. VTK is more up-to-date:
vtk: 5.4 (fink package vtk54-5.4.0-1)
but this doesn't seem to make a difference.
I just got back from my trip, so I'm going to try reproducing this. I'm a MacPorts guy, so I'm installing our vtk5 port right now. MP doesn't have a vtk-py port, so I'll need to put one together first assuming vtk5 builds alright here.
Based on the recommendations from your earlier email in the X11 list, I tried setting LIBGL_DIAGNOSTIC=1
When I run (and then close) the script that gives the "correct" rendering, imagepluspoly.py, I get:
initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: apple_glx_create_context: ac 0x2bdf10 ac->context_obj 0x94a400 DIAG: apple_glx_drawable_create: new drawable 0x98f400 DIAG: create_surface: created a surface for drawable 0x600002 with uid 181 DIAG: surface_make_current: ac->context_obj 0x94a400 s->surface_id 5 DIAG: surface_make_current: drawable 0x600002 DIAG: MakeContextCurrent: error NO DIAG: surface_notify_handler: surface destroyed 181 DIAG: destroy_drawable_callback: 0x98f400 ->reference_count before -- 2
When I run the script that gives the "wrong" behavior, gtkvtkdebug.py, I get:
initializing libGL in apple_init_glx DIAG: CGL major 1 minor 2 DIAG: apple_glx_create_context: ac 0x4f42810 ac->context_obj 0x9c7200 DIAG: apple_glx_drawable_create: new drawable 0xa08600 DIAG: create_surface: created a surface for drawable 0x60001e with uid 229 DIAG: surface_make_current: ac->context_obj 0x9c7200 s->surface_id 5 DIAG: surface_make_current: drawable 0x60001e DIAG: MakeContextCurrent: error NO
The only differences are the addresses and uids for the contexts and the drawables,
Yeah, could you figure out the visual id as well? I'm still curious why it's choosing a bad visual on my system.
and the last two lines which are output by imagepluspoly.py when it is closed are not output by gtkvtkdebug.py.
Hmm... that's not really a concern since the application is exiting. The server should notice the fd close and cleanup memory.
With LIBGL_ALWAYS_SOFTWARE=1, imagepluspoly.py gives:
but what is rendered is the same.
Ok, well that means it's not an nVidia issue. So it's either OpenGL.framework, X11 (less likely due to the email I just sent), or VTK (my money is on this one).
Trying this last suggestion, glxinfo -v gives: ...
plus 447 more Visual ID's that are the same except a few have redSize, greenSize, and blueSize, and alphaSize = 5.
I edited this output down a bit for brevity. Let me know if you need the full text. It was long.
No, I don't want the full text. I just want the one for the visual that is being used by your application. You need to set the LIBGL_DUMP_VISUALID environment variable when you run your application, and it will just print a hex number which is the visual id. Just copy/paste the info for that visual.