Re: Freezing updates for compositing managers
- From: Denis Dzyubenko <denis dzyubenko trolltech com>
- To: Owen Taylor <wm-spec-list gnome org>
- Subject: Re: Freezing updates for compositing managers
- Date: Fri, 17 Jul 2009 17:47:27 +0200
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
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]