[Xcb] Mixing VSync with XSync

[Michel Dänzer]

On 2021-07-08 11:12 a.m., Jonathan Purol wrote:
>> 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.
> 
> As far as I can tell I am doing that. the current loop looks something like this:
> https://privatebin.net/?7c57104ced0a8790#9Usgz9FTsXvTeoJmYQ5tVyMPs6sQKynb8LtXf39NnhsH <https://privatebin.net/?7c57104ced0a8790#9Usgz9FTsXvTeoJmYQ5tVyMPs6sQKynb8LtXf39NnhsH>
> 
> (non-highlighted version at the bottom for longevity purposes)
> 
> Although I might have understood wrong what you actually mean. From my PoV glXSwapBuffers should already "wait" until the frame is drawn, especially when we block afterwards using something like glClear(0) or glXWait*
> There's obviously a lot more code around that, but that's the basis of it.

I'm not sure which glXWait* you mean specifically, but drawing calls like glClear are not guaranteed to block until the swap has completed, depending on details of the GLX implementation, in particular how many buffers it uses behind the scenes.

It's best to use one of the APIs available for the explicit purpose of waiting for the swap to complete.


Note that I've come to realize what I described above isn't quite right yet. It's actually necessary to wait for the swap to complete before signalling to the compositing manager that the window contents are ready for the new size via _NET_WM_SYNC. Otherwise the compositing manager may draw a frame before the application buffer swap has completed, in which case the wrong window contents will be shown.


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