glxSwapBuffers in render thread with compositors missing update
michel at daenzer.net
Mon Jun 1 18:46:11 PDT 2015
On 01.06.2015 00:41, Roland Plüss wrote:
> 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
> - 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?
Compositors get notified of updates to drawables via Damage events, not
Which OpenGL implementation / driver are you using?
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the xorg