[Xquartz-dev] Bug in displaying vtk objects

Valerie Coffman valerie.coffman at nist.gov
Wed Jun 17 11:32:41 PDT 2009


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, and the last two lines which are output by imagepluspoly.py 
when it is closed are not output by gtkvtkdebug.py.

With LIBGL_ALWAYS_SOFTWARE=1, imagepluspoly.py gives:

initializing libGL in apple_init_glx
DIAG: CGL major 1 minor 2
DIAG: Software rendering requested.  Using kCGLRendererGenericFloatID.
DIAG: apple_glx_create_context: ac 0x2bdf10 ac->context_obj 0x94a400
DIAG: apple_glx_drawable_create: new drawable 0x95fa00
DIAG: create_surface: created a surface for drawable 0x600002 with uid 245
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 245
DIAG: destroy_drawable_callback: 0x95fa00 ->reference_count before -- 2

and gtkvtkdebug.py gives:

initializing libGL in apple_init_glx
DIAG: CGL major 1 minor 2
DIAG: Software rendering requested.  Using kCGLRendererGenericFloatID.
DIAG: apple_glx_create_context: ac 0x4f42810 ac->context_obj 0x9c7200
DIAG: apple_glx_drawable_create: new drawable 0x9d8600
DIAG: create_surface: created a surface for drawable 0x60001e with uid 253
DIAG: surface_make_current: ac->context_obj 0x9c7200 s->surface_id 5
DIAG: surface_make_current: drawable 0x60001e
DIAG: MakeContextCurrent: error NO

but what is rendered is the same.


> So it turns out the vtk-py stuff is in MacPorts' vtk5 port already, so 
> I'm giving it a go.  The two gtk scripts fail outright for me using 
> MacPorts with either Mesa's libGL or our new hardware accelerated 
> libGL.  I see:
>
> The program 'gtkvtkdebug2.py' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadValue (integer parameter out of range for operation)'.
>   (Details: serial 20 error_code 2 request_code 0 minor_code 3)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error() 
> function.)
>
> Here's the stack with our hw accelerated libGL:
>
> #0  0x0072e08c in gdk_x_error ()
> #1  0x018e274c in _XError ()
> #2  0x055adfa4 in __glXSendError (dpy=0x8af400, errorCode=2, 
> resourceID=34, minorCode=3, coreX11error=true) at glx_error.c:59
> #3  0x055809f4 in CreateContext (dpy=0x8af400, vis=0x7322e40, 
> fbconfig=0x0, shareList=0x0, allowDirect=1, contextID=0, 
> use_glx_1_3=0, renderType=0) at glxcmds.c:388
> #4  0x05580b30 in glXCreateContext (dpy=0x8af400, vis=0x7322e40, 
> shareList=0x0, allowDirect=1) at glxcmds.c:416
> #5  0x0534a2b0 in vtkXOpenGLRenderWindow::CreateAWindow ()
> #6  0x0534b6d4 in vtkXOpenGLRenderWindow::WindowInitialize ()
> #7  0x0534b7f0 in vtkXOpenGLRenderWindow::Initialize ()
> #8  0x0534bc88 in vtkXOpenGLRenderWindow::Start ()
> #9  0x0523edc0 in vtkRenderWindow::DoStereoRender ()
> #10 0x0523ed74 in vtkRenderWindow::DoFDRender ()
> #11 0x0523e6f8 in vtkRenderWindow::DoAARender ()
> #12 0x0523db58 in vtkRenderWindow::Render ()
> #13 0x0534e9d0 in vtkXOpenGLRenderWindow::Render ()
> #14 0x04f2e67c in PyvtkXOpenGLRenderWindow_Render ()
> ...
>
> (gdb) frame 3
> #3  0x055809f4 in CreateContext (dpy=0x8af400, vis=0x7322e40, 
> fbconfig=0x0, shareList=0x0, allowDirect=1, contextID=0, 
> use_glx_1_3=0, renderType=0) at glxcmds.c:388
> 388        __glXSendError(dpy, BadValue, vis->visualid, 
> X_GLXCreateContext,
> (gdb) print mode
> $1 = (const __GLcontextModes *) 0x0
>
> ^^^ This is why we're seeing an error.  We couldn't get a valid mode 
> for the requested visual id:
>
> (gdb) print vis->visualid
> $2 = 34
>
> So we were told to use an invalid visual by 
> vtkXOpenGLRenderWindow::CreateAWindow
>
> I'm curious how you guys are getting yours to render.  Perhaps this is 
> an issue that is fixed in fink's version of vtk.  Can you set the 
> LIBGL_DUMP_VISUALID environment variable?  that should tell you which 
> visual is being requested, and you can find out about that visual by 
> running 'glxinfo -v'.
>
> --Jeremy
>

Trying this last suggestion, glxinfo -v gives:

name of display: /tmp/launch-LSCUAM/:0
visualid 0x72
visualid 0x4a
display: /tmp/launch-LSCUAM/:0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_rating,
    GLX_SGIX_fbconfig
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_rating,
    GLX_SGIX_fbconfig
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL version string: 2.0 NVIDIA-1.5.44
OpenGL shading language version string: 1.20
OpenGL extensions:
    GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_vertex_blend,
    GL_ARB_window_pos, GL_ARB_shader_objects, GL_ARB_vertex_shader,
   
... SNIP ...


448 GLX Visuals
Visual ID: 24  depth=24  class=TrueColor
    bufferSize=32 level=0 renderType=rgba doubleBuffer=0 stereo=0
    rgba: redSize=8 greenSize=8 blueSize=8 alphaSize=8
    auxBuffers=0 depthSize=0 stencilSize=0
    accum: redSize=0 greenSize=0 blueSize=0 alphaSize=0
    multiSample=0  multiSampleBuffers=0
    visualCaveat=Slow

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.

Thanks so much for your help!

Valerie





More information about the Xquartz-dev mailing list