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