[Xcb] Frame synchronization

[Sam Varshavchik]

VaL writes:

> If we continuously update content of the window (e.g. showing an animation),  
> and this window is being resizing at the same time,
> does it mean, that we do NOT have a control to sync our flushing and  
> resizing?
> Because _NET_WM_SYNC_REQUEST event is not received yet or it is in event  
> queue but the geometry is already changed?
> And we update the window with old geometry before we handle the sync request.
>
> Using the extended sync, will WM reconfigure the window after it "receives"  
> updated sync req counter (with odd value)?
> And should not change the geometry in other cases.
> Or is it the same as basic, when after sync req is sent, then the window  
> gets resized?

Theoretically, the extended synchronization options would allow these  
situations to be handled intelligently. The window manager knows that it  
wants to resize the window, and knows that the client supports the extended  
synchronization protocol. So, after making the decision that the window  
needs to be resized, the window manager sends _NET_WM_SYNC_REQUEST followed  
by immediate window resize; and  then stops updating the real window, from  
the redirected buffer, until the client receives the message, subsequent  
ConfigureNotify and Exposure events, redraws its window, and sets its timer  
to what it received in _NET_WM_SYNC_REQUEST, ignoring any interim updates.

The key word in the above paragraph is "theoretically".

And no matter what you do. No matter how much you bend over backwards, there  
is absolutely nothing you can do about core fundamental ways in which X  
works. There is nothing you can do about the fact that the X server will, at  
some point, resize the actual window, and send you the requisite configure  
and exposure events, but you haven't received them yet, and you're still  
spewing out rendering messages that update the window whose size is now  
different. And you have no way of determining that.

As far as I can see, extended synchronization seems to have a theoretical  
ability to solve this problem. In theory, as far as I understand the  
extended synchronization spec, the window manager effectively intercepts and  
redirects all client rendering; the window manager knows that it's going to  
resize the window, so it can stop updating the real window from the off- 
screen buffer that the client is updating, until the client acknowledged,  
via the timer update, that it is now aware of the new window size and has  
updating the redirected off-screen buffer's contents with what the window  
should have, in its new size.

But, all of that ass-umes that this is how the window manager, and the  
client, work, and they work correctly in all respects.

> Could the extended sync method be a solution for these continuous updates?

Sure, theoretically it can. Whether it will in practice, is unknown. If your  
specific window manager does this, and does this correctly, great. You found  
a solution. But for yourself only. But you have no guarantee that everyone's  
window manager implements extended synchronization. I know that XFCE's  
window manager does not. You have no guarantees that your window manager  
supports even basic synchronization, actually. If your intent is for things  
to work well in every possible situation, you'll have to make the best job  
you can, and I don't see a guaranteed way to avoid some display artifacts,  
in all situations.

> I've tried to use extended version, but unfortunately the same issue, when  
> the updates are done only after sending req counter, like
> <- sync req counter is received from WM
> -> increased, means begin frame
> .. update
> -> increased, end frame.
> .. update
>
> <- sync req counter is received
>
> If no second update, everything is ok.

It's hard to say anything here. The devil is in the details. Now, without  
having the extended specs in front of me, I'm pretty sure you have to  
increase the counter again, before rendering the next frame, and coordinate  
the incrementating using _NET_WM_FRAME_DRAWN messages. That is, after  
marking the end of the frame, you're not supposed to do anything until you  
get a _NET_WM_FRAME_DRAWN. Then you increment the counter, render your  
frame, increment the counter again, and then wait for another  
_NET_WM_FRAME_DRAWN, and so on.
 
I haven't had the need to use extended synchronization (and I couldn't since  
the window manager I use doesn't implement it), so I might be wrong on some  
aspect of this, but this was I thought the process was, when I read through  
it, some time ago.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/xcb/attachments/20190219/1b5b2a2f/attachment.sig>