[Xquartz-dev] Bug in displaying vtk objects

Jeremy Huddleston jeremyhu at apple.com
Wed Jun 17 11:03:14 PDT 2009


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.
>
>> 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.

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



More information about the Xquartz-dev mailing list