[Xquartz-dev] Bug in displaying vtk objects

johan stalpaert johan.stalpaert at pandora.be
Wed Jun 17 13:47:07 PDT 2009


Could you please remove me from the distribution list?
Thank you.
Regards
Johan Stalpaert
On 17 Jun 2009, at 20:44, Jeremy Huddleston wrote:

>
> 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.
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>

johan stalpaert
johan.stalpaert at pandora.be





More information about the Xquartz-dev mailing list