glxSwapBuffers in render thread with compositors missing update

[Michel Dänzer]

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
> 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?

Compositors get notified of updates to drawables via Damage events, not
Expose events.

Which OpenGL implementation / driver are you using?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer