[Xquartz-dev] Some opengl windows blacked out with 2.3.3rc2

[George Peter Staplin]

Quoted Martin Otte <otte at 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/