[Xcb] Frame synchronization

[Sam Varshavchik]

VaL writes:

> So let's figure out base sync flow:
>
> <- When _NET_WM_SYNC_REQUEST is sent, does it mean that the window is  
> already frozen?
> <- XCB_CONFIGURE_NOTIFY sent with new geometry
> <- XCB_EXPOSE to expose the window, and it is still frozen, right?
> ... We do flush here and update content of the window
> -> And send _NET_WM_SYNC_REQUEST_COUNTER back to the WM, and after this the  
> window _not_ frozen anymore?
>
> !!!... the problem here, when we do flushing/updating content right here,  
> the content of the window is jumping, and resizing is not smooth.
> Looks like it has wrong/outdated geometry. Does the window have new geometry  
> or still resizing?

_NET_WM_SYNC_REQUEST does not change the core X protocol. As always,  
ConfigureNotify indicates that the window was resized, and ExposeNotify  
indicates which parts of the window should be repainted.

Your X client may receive ExposeNotify events with or without a preceding  
ConfigureNotify. Furthermore, as explained in the X protocol specification,  
there could be one or more ExposeNotify events. Additionally, the window  
gravity setting also controls which parts of the window are considered to be  
exposed after the window gets resized.

That's the core X protocol behavior. _NET_WM_SYNC_REQUEST does not change  
that. The only thing that _NET_WM_SYNC_REQUEST brings to the table is that  
it is sent before the window manager resizes the window. Hence, the  
application receives it before it receives ConfigureNotify. Furthermore, the  
window manager will avoid resizing the window again until the application  
updates the timer, as specified by the synchronization protocol.

Whether the application updates the timer before or after it receives an  
exposure event, or before or after it actually draws the window, it is  
immaterial as far as the synchronization protocol is concerned. As far as a  
window manager is concerned, it is waiting for the timer before it continues  
resizing the window.

As a postscriptum, I found that XFCE's window manager sets a moderately  
short timeout waiting for the app to update the sync timer. About half a  
second in my estimation. If the application fails to update the timer, the  
window manager considers the application to be broken and will no longer  
send it sync request.

> <- new _NET_WM_SYNC_REQUEST is sent, does it mean that the window is frozen  
> again after/before/same time the event is sent?
> <- XCB_CONFIGURE_NOTIFY
> <- XCB_EXPOSE
> -> _NET_WM_SYNC_REQUEST_COUNTER is sent back

Nothing is "frozen". There is no such thing as "frozen", here.

> So the update of the window is requested after _NET_WM_SYNC_REQUEST_COUNTER  
> is sent and before new _NET_WM_SYNC_REQUEST is received.

The window manager resizes the window after sending the sync request. End of  
story. The same thing is observed by the client. It receives a  
_NET_WM_SYNC_REQUEST, followed by ConfigureNotify, and/or any expose events  
that follow it. Whether or not, in actuality, the window manager resizes the  
window, in relativistic spacetime, before the client receives the  
synchronization request, is entirely up to the luck of the draw. It may or  
may not happen each individual time. Neither the window manager, nor the  
client, has any means of controlling it. Whether that happens, or not,  
depends entirely on external factors. Such as whether one or the other –  
the window manager, or the client – is running locally, or running in a  
tunneled X connection on the other side of the Earth, or a different planet  
altogether. All of these factors, and many others, will decide whether or  
not the window manager ends up actually resizing the window before or after  
the client receives the _NET_WM_SYNC_REQUEST message.

> So the question is:
> Is the actual window's geometry being changed strongly after  
> _NET_WM_SYNC_REQUEST_COUNTER is received by WM and strongly before  
> _NET_WM_SYNC_REQUEST is sent to the client?

Neither. The WM reconfigures the window after it sends a  
_NET_WM_SYNC_REQUEST message to the client. The End.

Furthermore, the WM does not "receive" something called  
"_NET_WM_SYNC_REQUEST_COUNTER", at any point. "_NET_WM_SYNC_REQUEST_COUNTER"  
is a property the client sets on its window. The window manager reads it, at  
some point. That's immaterial as far as the synchronization protocol is  
concerned.

> Is extended frame sync protocol supposed to handle a case with sudden window  
> updates like this?

The extended frame sync protocol is supposed to handle a more sophisticated  
situation, where the window manager redirects the actual X client window to  
an off-screen buffer, and this is the means of informing the window manager  
when it can compose the buffered contents of the window onto the real  
display.


-------------- 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/29fbe0a8/attachment.sig>