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?