Re: Standardizing _METACITY_UPDATE_COUNTER
- From: Owen Taylor <otaylor redhat com>
- To: Soeren Sandmann <sandmann daimi au dk>
- Cc: Havoc Pennington <hp redhat com>, gtg990h mail gatech edu, wm-spec-list gnome org, gtk-devel-list gnome org
- Subject: Re: Standardizing _METACITY_UPDATE_COUNTER
- Date: Sun, 22 Feb 2004 13:01:18 -0500
On Sun, 2004-02-22 at 10:42, Soeren Sandmann wrote:
> - 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.
I don't quite understand how the window manager is robust here; of
course, it can't crash under any circumstance, but since it can't tell
that these left over counter increments are from previous
ConfigureNotifies, it has no way of ignoring them, it just has to
assume that they are in acknowledgements of its resizes.
Yes, this is a corner case, since normally things will catch up
and when there are no outstanding resizes the counter increments
can easily be ignored.
But I don't think it's that uncommon that:
- Window is resized before it is mapped so has a queued ConfigureNotify
- User starts resizing the window as soon as it is mapped
- App is slow on painting newly mapped windows and on resizing so
never catches up with the window manager.
So that's why I'm suggesting the serial approach since it eliminates
this problem. A valid point? Obsession with detail? I'll let other
To resummarize my proposal:
The window manager sends a client message
data.l, data.l 64 bit counter
which means "Once you are done processing the next ConfigureNotify
and associated exposes, acknowledge that you are done by echoing
the counter value value back to me." (Via client message or
XSYNC, protocol could be either way.)
The client is allowed to compress multiple ACKNOWLEDGE_CONFIGURE
client messages and the associated ConfigureNotify events and just
use the latest counter value.
] [Thread Prev