Comment 1 for bug 1030891

This indicates a broken driver to me, as the spec says you're not supposed to do that:

#5 0x00007ffff6d22a41 in XOpenDisplay () from /usr/lib/x86_64-linux-gnu/libX11.so.6
No symbol table info available.
#6 0x00007fffea05fc62 in vboxstub_glXBindTexImageEXT () from /usr/lib/x86_64-linux-gnu/dri/vboxvideo_dri.so
No symbol table info available.

---

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()

In any case we'll have to work around it, I don't want to revert this revision as it will cause regressions on nvidia.