Re: Standardizing _METACITY_UPDATE_COUNTER
- From: Soeren Sandmann <sandmann daimi au dk>
- To: Havoc Pennington <hp redhat com>
- Cc: gtg990h mail gatech edu, wm-spec-list gnome org, gtk-devel-list gnome org
- Subject: Re: Standardizing _METACITY_UPDATE_COUNTER
- Date: 22 Feb 2004 16:42:43 +0100
I guess my first mail wasn't too clear. This one is hopefully more to
Havoc's patch and the Qt patch
- Havoc's GTK+ patch is different from the Qt patch. Havoc's
patch makes gtk+ bump the counter every time anything
changed for any reason. The Qt patch (as I understand
Raynier's explanation) bumps the counter whenever it has
seen a number of ConfigureNotifies and finished handling
- Havoc's patch does not work. If the application window
contains an animation, then the patch will send a stream of
counter bumps that will cause the window manager to keep
resizing even though the application possibly haven't even
*seen* the previous ConfigureNotifies.
- I don't see any reason the Qt approach wouldn't work (but
see below for why I think it can be improved).
- Every time the toolkit sees a configure notify (before
compression or anything else) it increments a (plain old
C/C++) variable called "unacknowledged_configure_notifies"
- When the toolkit has finished layouting and drawing, it
increments the X SYNC counter by the value of u_c_n and
resets u_c_n to 0.
- The window manager generally sends a ConfigureNotify and
waits for the toolkit to acknowledge it.
- If the toolkit doesn't acknowledge within n ms, the window
manager should go ahead and send another ConfigureNotify,
ie. the window manager does have a timeout. I did *not*
suggest getting rid of the timeout.
So the one-to-one approach is totally simple. No complicated
anti-race-condition stuff. And there _is_ a timeout. In fact, the only
difference from the Qt patch is that instead of always bumping the
SYNC counter by 1, it bumps by the number of ConfigureNotifies it has
If the window manager in the common (non-timeout) case only sends a new
ConfigureNotify when it has seen the acknowledgment of the preivous
one, then the application will only ever see one ConfigureNotify in
its queue and will never bump by anything else than 1, ie. exactly as
the Qt case.
What's the point then?
- The description of the application-side algorithm is simpler and
"Increment the counter when the application has done the
processing associated with the ConfigureNotify, ie. the counter
represents the number of handled ConfigureNotifies. "
That doesn't involve the notion of "full frame", which may not make
any sense for some toolkits. The concept "processing associated with
ConfigureNotify (whether delayed or not)" _does_ make sense for all
- The window manager can keep track of where in the ConfigureNotify
stream the application is.
This means a window manager can have the policy that an application
can be up to "k" ConfigureNotifies behind. A sophisticated window
manager could even measure the time an application usually takes to
handle a configure, factor in the round trip time, and base its
value of "k" on that. Yes, that's complex, but window manager don't
have to do it if they don't want. But with the one-to-one approach
they have the possibility.
Note that if the window manager has the (reasonable) policy of
"k == 1", the whole thing is exactly equivalent to the Qt approach.
I don't think these two points are total killer advantages, but I do
think they make it worthwhile making the very simple change from
"say when you have handled _some_ ConfigureNotifiy"
"say _how many_ ConfigureNotifies you have handled".
Because the last one isn't at all difficult to implement and it
significantly increases the amount of information the window manager
- When a window manager first manages a window, the
application could have queued up a number of
ConfigureNotifies. To the window manager this will look like
spurious counter updates, something which it must be robust
against under all circumstances.
This doesn't break anything; a window manager should just
know that the counter updates come from an unreliable
source. That will be the case under all the schemes.
- Do we acknowledge synthetic ConfigureNotifies? Yes, as Lubos
points out, it is hopeless to try to figure out which ones
] [Thread Prev