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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]