Re: Standardizing _METACITY_UPDATE_COUNTER

[Soeren Sandmann <sandmann daimi au dk>]

gtg990h mail gatech edu writes:

> The kwin side of the patch is about to go into CVS, so Lubos Lunak suggested  
> contacting the metacity developers about standardizing this behavior, or at 
> least making it public so things don't change unexpectedly. Also, it appears 
> that the toolkit side of the patches have not made it into GTK+. Standardizing 
> the behavior might make it easier to get GTK+ and Qt to support the sync 
> counter. Lastly, the freedesktop.org X server will make it possible to 
> double-buffer window resizes like MacOS X does, and as noted in the original 
> message, the sync counter makes that possible.   

The idea of the counter is to make sure the window manager doesn't
resize the application window more often than the application can keep
up drawing (which is the main reason for the annoying "lag" effect of
opaque resizing). But the window manager should also not send _fewer_
ConfigureNotifies than the application can handle, because that will
just decrease the smoothness of the resizing for no good reason.

Havoc's idea is to associate an X SYNC [1] counter with the
application window. Every time the application has finished handling a
ConfigureNotify it should increase that counter, and the window manager
should only send a new ConfigureNotify when it has seen the
application increase the counter.

The reason Havoc's patch, as it stands, should not be applied to gtk+
is that it makes gtk+ increment the counter every time gtk+ finishes
drawing. Of course, gtk+ will draw when one of its windows is resized
by the window manager, but it will also draw in other situations, eg.,
because an animation is running. In that case Havoc's patch would
cause gtk+ to keep increasing the counter, which could in theory
(though perhaps not in practice) make the window manger send a stream
of resizes - thus re-introducing the lag we are trying to
avoid. Basically, the problem is that it has a
"many-increments-to-one-configure-notify" relationship. As I recall,
fixing the patch didn't seem terribly difficult.

I think it is important that the spec will say something to the effect
of

	"The application must increase the counter exactly when it has
	 finished handling a ConfigureNotify that was sent/caused by
	 the window manager. Thus, there must be a one-to-one
	 relationship between ConfigureNotifies and counter
	 increments."

My argument is that

	- if there is a "many increments to one ConfigureNotify"
	  relationship, then the window manager will (potentially)
	  send ConfigureNotifies before the application has handled
	  the existing ones, producing lag.

	- if there is a "few increments to many ConfigureNotifies"
	  relationship, then there will be ConfigureNotifies that the
	  window manager will not know have been handled, thus
	  producing stuck windows.

So one-to-one is the only possibility. Note that the application
can still (and should) compress multiple ConfigureNotifies and handle
them all at once. In that case it should send a "COUNTER += n"
message, where n is the number of compressed events.

More WM-savvy people than I will have to say if there is the
possibility in a non-broken-setup, that an application can receive
ConfigureNotifies that the window manager doesn't know about. If there
is, then something will probably have to be done to take care of that
(though a window manager should be robust against spurious counter
increments).

Another point: I don't think the spec should rule out that a window
manager can send more ConfigureNotifies before seeing the
acknowledgments of the preceding ones. A window manager could
conceivably have the policy that "the application can be up to n
ConfigureNotifies behind". Metacity's policy is to have n==1, but I
don't think 'n==1' should be set in stone.



Søren