Quoted Martin Otte <otte@duke.edu>:
I just upgraded to 2.3.3_rc2 from 2.3.2, and everything works fine except for one application (IDL) where all opengl windows are blacked out. If I click and drag/rotate the visualization in the window, the correct scene will flash momentarily but the window will again be entirely black when I stop moving the visualized surface.
Everything worked fine with 2.3.2 and earlier versions. Since it is a commercial product, I can't help with any source code examples.
Thanks, Martin
That seems to be a known issue due to enabling the surface destruction notification. I believe someone else also reported a similar issue with the same product. The old X server code wasn't notifying clients that the OpenGL surfaces had been destroyed. If I recall my test case correctly, these types of patterns were leaking: glXMakeCurrent(dpy, window, ctx); glXMakeCurrent(dpy, anotherWindow, ctx); So if a client destroyed and created many windows over time, and made them current, the associated memory on the client side would grow. The libGL code receives an event to indicate that a surface was destroyed, due to a window being destroyed, and the old code wasn't doing that. Once I enabled the notifications (by fixing an X server bug) to fix a memory leak that was occurring in a test case, we ran into these types of problems. I'm still trying to fix it, because it turns out that it brought forth 2 other issues by trying to test for and fix these memory leaks. The second issue is that withdrawn windows lose all of their OpenGL surfaces, and I didn't find that until recently when running the glut test suite. The issue was found by testing, but had been in the old libGL and X server code too. It's now in hindsight a problem that has been there for a while (since before I worked on any of this code at least). When a window is withdrawn, it loses its surfaces, and then is subsequently remapped, its contents are lost, and the OpenGL operations fail. Note: a withdraw operation isn't the same as an iconify. The problem is that the XReparentWindow, and XDestroyWindow operations done in response by window managers result in the destruction of all surfaces for the toplevel, even though part of the window hierarchy still exists, and the code expects to have OpenGL surfaces that are valid. I believe we will resolve these issues. Thank you, for notifying us of the problem. It's often helpful to know that it occurs for more than one person with the same product. George -- http://people.freedesktop.org/~gstaplin/