[Xcb] Frame synchronization

[VaL]

Dear all,
trying to implement smooth resizing using XCB frame basic or extended synchronization protocol, but still have some doubts how it is supposed to work.

The biggest issue is that we would need to update the window separately and regardless of XCB_EXPOSE events (within actual resizing)
When we update the window with outdated geometry, when the window is being resizing.

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?

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

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.
This produces some twitching/jumping during resizing.

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?

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

The same behavior is observed when we use extended sync counter,
<- Received a counter, even value
-> Increased to odd and sent back, the window gets frozen
... flush
-> Increased to even again and sent again, after this the window is not frozen (??)
!!!!!... window flush -- and the problem persists, it is flushed with wrong geometry, the same logic as basic frame sync.
<- Received a counter

So tried to send odd value before we start flushing
<- Received a counter, even value
-> Increased and sent back, the window gets frozen
... flush
-> Increased again and sent
....
-> Increased to odd and sent back, notifying that we start flushing!
here we would expect to freeze the window, until we sent the even counter back.
But it did not work
<- We either just received new counter from WM or it gets stuck or..

Should we receive new counter here? After second sending the odd counter (start flushing)?
Should the window be frozen in this case?

But we would like to flush window strongly when its geometry is not changing.

Just an example, you could try any Qt example with opengl and try to resize and see the issue.

Let's figure out how it is supposed to work by design regardless WM.

Best regards and thanks,
-
   VaL