glXBindTexImageEXT is not compliant -> fixed as of 1 Oct 2012 (4.2 and later)

[smspillaz]

glXBindTexImageEXT opens a new X connection on the first time it is invoked when the client may have a server grab. This is not compliant with the specification:

​http://developer.download.nvidia.com/opengl/specs/GLX_EXT_texture_from_pixmap.txt

5. Should users be required to re-bind the drawable to a texture after

the drawable has been rendered to?

It is difficult to define what the contents of the texture would be if we don't require this. Also, requiring this would allow implementations to perform an implicit copy at this point if they could not support texturing directly out of renderable memory.

The problem with defining the contents of the texture after rendering has occured to the associated drawable is that there is no way to synchronize the use of the buffer as a source and as a destination. Direct OpenGL rendering is not necessarily done in the same command stream as X rendering. At the time the pixmap is used as the source for a texturing operation, it could be in a state halfway through a copyarea operation in which half of it is say, white, and half is the result of the copyarea operation. How is this defined? Worse, some other OpenGL application could be halfway through a frame of rendering when the composite manager sources from it. The buffer might just contain the results of a "glClear" operation at that point.

To gurantee tear-free rendering, a composite manager would run as follows:

-receive request for compositing: XGrabServer() glXWaitX() or XSync() glXBindTexImageEXT()

<Do rendering/compositing>

glXReleaseTexImageEXT() XUngrabServer()

This results in a deadlock on startup with recent versions of compiz.

A patch to fix this is attached.

[Michael Thayer]

Thanks for pointing that out. I made a similar change (your patch didn't actually compile) to trunk and 4.2 today.

[Frank Mehnert]

Fixed some time ago.