[Xcb] Frame synchronization

[VaL]

20.02.2019, 00:55, "Sam Varshavchik" <mrsam at courier-mta.com>:
>>  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.
>

If there is no any more resizing, 
you increment the counter, render your frame, increment again and wait for _NET_WM_FRAME_DRAWN, 
but it is not sent, there is no more _NET_WM_FRAME_DRAWN events? 

In my case, the window gets stuck and no updates, so how to know that we can continue updating the window again?

I've tried to stop updating the window if a resizing is started (received sync counter), and continue the updates when _no_ new sync request counters are received within 30ms (configurable).
This approach works, but it would be great to understand could it be fixed by sync protocol without hacks like this.

Ideally I would want to have something like:
1. The WM says that the window is going to be resized, sends an event to the client. The size is not yet changed.
2. Flush the window, is ok, the geometry is not changed yet.
3. The client receives this event, sends an event back, that it is going to start flushing the window. It is beginFrame. Waiting for geometry.
4. The geometry is changed and sent to client.
5. Using new geometry, flush the window.
6. Sends an event that frame is finished, endFrame.
7. Flush, without any events, should be ok, because the size is not changed, guaranteed to be unchanged.
8. GOTO 1

So it would be good if the real size of the window is changed only after client's acknowledge, that it is ready to redraw the window.

But currently seems the size is changed without client's action and there is always a possibility to redraw the window with outdated geometry, right?
Because based on your comments, the actual resizing of the window is done after step 1.
And step 2 could introduce the issue when the geometry is changed, but window is flushed with old geometry.

Thanks

PS. My original hack was to avoid any window updates between few sync requests, and wait for a while after last seen sync request counter to start updating again, which meant as resizing is already finished.
It is avoiding step 2 and step 7.

-- 
    VaL