[Xcb] Mixing VSync with XSync

Michel Dänzer michel at daenzer.net
Thu Jul 8 08:28:59 UTC 2021

On 2021-07-07 6:03 p.m., Folling wrote:
> Hello xcb mailing list.
> This is my first e-mail in this or similar mailing lists, please let me know if I'm doing anything wrong and I will
> improve it in further messages.
> I've recently started developing my own GUI library and in turn an interface with the X server (windowing, input, etc.).
> My GUI runs fully hardware accelerated via OpenGL and GLX. Everything works splendidly. Then I tried to replicate smooth
> resizing using the XSync extension, and that's where problems arose.
> The problem is namely using the extension in conjunction with the VSync interval.
> Not using VSync makes this rather simple. I have one thread where I handle X events, and another thread where I render.
> The latter then waits on a conditional variable which is woken up by the event-thread once a resize is requested and
> then handles that accordingly. That works wonderfully but I would like to have VSync enabled as it should get rid of
> screen-tearing, especially with freesync/gsync enabled. I could of course just run a separate thread at slightly below
> the refresh rate of the monitor to add render requests periodically to a queue, but that seems very hacky and UB to me.
> What doesn't work however is if the render thread blocks after each render call (which happens after glXSwapBuffer, or
> rather in my case after the first OpenGL call after swapping the buffers). In this case the resize, whilst still very
> smooth, has artifacts, such as the content of the window overlapping the window's border, or the content of the window
> not stretching for the entirety of the border.
> I am very certain that this is an issue on my end, as both Qt and GTK applications with OpenGL windows don't have this
> problem, even when I explicitly enable VSync.
> What I did find wasthe extended XSync mechanism using a second counter:
> https://fishsoup.net/misc/wm-spec-synchronization.html
> But sadly that isn't supported by my WM (KDE Plasma, I checked that using `_NET_SUPPORTED`), which makes this not usable
> for me as I want to support a wide array of systems. Furthermore this shows that it has to be possible without that
> extended version of XSync.

Indeed. The main trick is to always wait for the previous buffer swap to complete (using GLX_INTEL_swap_event or GLX_OML_sync_control) before drawing the next frame. Then the normal _NET_WM_SYNC protocol should work.

Earthling Michel Dänzer               |               https://redhat.com
Libre software enthusiast             |             Mesa and X developer

More information about the Xcb mailing list