glxSwapBuffers in render thread with compositors missing update

The special situation is this:

  • A toolkit driven application (FOX-ToolKit in this case)
  • Render window is “injected” into the framework (so this means no influence to X11 event loop handling of the application)
  • Main Thread: Does everything not touching OpenGL (in particular has no GL context assigned nor created)
  • Render Thread: Does all OpenGL related rendering on a separate Display connection
  • glXSwapBuffers: called during synchronization time when both threads get in touch with each other

In general this situation works. I can have multiple windows in the toolkit all of which are rendered sequentially in the render thread and display updates properly.

The problem now is if a Compositor comes into play and today this seems to be omni-present. With the compositor enabled the glXSwapBuffers is sort of “ignored” by the compositor in the main thread. Basically the compositor updates the first rendered frame and all consequtive glXSwapBuffers are ignored. If I disable the compositor though all glXSwapBuffers work splendid.

My conclusion is that glXSwapBuffers in the second thread does properly notify X-Server about the swap of the front and back buffer but the compositor is somehow left out in the dark.

My question is now does somebody know how I can force an update onto the compositor? I tried already sending an Expose event with XSendEvent to the main thread display connection but this had no effect. I guess I have to get more creative to kick the compositor in the butts?

[QUOTE=Dragon;1266744]The special situation is this:

  • glXSwapBuffers: called during synchronization time when both threads get in touch with each other
    [/QUOTE]
    What does that mean? Which one of the threads calls the function?

Is it by any chance a single buffered context? I had a similar problem and it turned out that for single buffered contexts glXSwapBuffers doesn’t even
have to do the ‘implicit flush’, requiring a manual glFlush call.

The main thread waits for the render thread to finish (if not finished already) and then synchronizes states for the next round. The render thread then start out by first doing a glXSwapBuffers (show what has been async rendered) before rendering the new frame. So basically glXSwapBuffers is called in the render thread using the display connection opened in the render thread (different from main thread in the toolkit I have no access to).

Is it by any chance a single buffered context? I had a similar problem and it turned out that for single buffered contexts glXSwapBuffers doesn’t even
have to do the ‘implicit flush’, requiring a manual glFlush call.

No, it’s double buffered. It works if rendering synchronous but not asynchronous so I assume due to the second display connection with opengl stuff going on the compositor does not realize it has to update the drawable. I tried also calling XSync, XFlush in both threads but no dice.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.