Re: Freezing updates for compositing managers

Hi Owen,

Sorry for the late reply. Now when things settled up and I thought a bit 
about it your last solution sounds almost perfect.

Owen Taylor wrote:

> But what if we turned _NET_WM_SYNC_REQUEST_COUNTER into a more
> general frame counter. With the following handling:
> 
>  - When the client starts drawing a frame, it increments the counter to
>    an odd value to freeze updates.
>  - When the client finishes drawing, it increments the counter to an
>    even value to thaw updates.
>  - When the window manager wants to do a sync, it picks an even value
>    at least a 100 [arbitrary] values ahead of the last value it
>    received from the client and sends _NET_WM_SYNC_REQUEST to the
>    client with that value. The client then uses that value on the
>    frame completion after processing the resize.

In your email you mentioned a possible need for the second counter - so 
what if we extend the NET_WM_SYNC_REQUEST specification to include a 
second counter, so that the NET_WM_SYNC_REQUEST_COUNTER property will 
contain two counters.

* The first counter should be set by the client as a response to the 
_NET_WM_SYNC_REQUEST client message (all according to the current 
specification).
* The second counter is set by the client when it wants to freeze 
updates and its value can be arbitrary (i.e. doesn't depend on the 
ConfigureNotify/ClientMessage pair).

This way we maintain backward compatibility - if the 
windowmanager/compositor doesn't know about the second counter, they'll 
just ignore it and get only the first counter with a 
XGetWindowProperty() call.

It should also be completely safe if the client doesn't support having 
two counters, but the window manager does - the GetWindowProperty() will 
just return the first item and the window manager can easily check how 
many counter are actually there.

> Advantages of this:
> 
>  - It has the same race-condition-free-startup and no-round-trip on
>    updates as my proposal.
> 
>  - It integrates with the sync request system in an aesthetically
>    pleasing fashion.

The same advantages apply and I can only see one possible disadvantage - 
if the wm/compositor doesn't handle counter updates that are done not in 
the response to the ConfigureNotify, but I'd expect window managers to 
handle this case pretty well since there is always a possibility of 
broken client that doesn't use the NET_WM_SYNC_REQUEST protocol properly.


I've made a test implementation of this for Qt:
http://pastebin.ca/1498362?nomobile=1
(the patch is against Qt master (trunk) which has already introduced 
support for the original _NET_WM_SYNC_REQUEST protocol).

-- 
Denis Dzyubenko
Software Engineer
Nokia, Qt Software