[Xquartz-dev] Bug in displaying vtk objects

Jeremy Huddleston jeremyhu at apple.com
Wed Jun 17 11:44:35 PDT 2009


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.



More information about the Xquartz-dev mailing list