Re: Standardizing _METACITY_UPDATE_COUNTER

[Owen Taylor <otaylor redhat com>]

On Sat, 2004-02-21 at 09:55, Soeren Sandmann wrote:
> 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.

I tend to agree with where you are going here. The thing that bothers me
about _METACITY_UPDATE_COUNTER and about the patch in particular is that
there is no information passed around that correlates what the window
manager is doing with what 

If I understand you correctly, you are suggesting that this correlation
be "contractually" enforced by the requirement that the application 
only update the counter once per ConfigureNotify received from the 
window manager. (Does this include the synthetic ConfigureNotifies that
are sent on moves as welll as the real ConfigureNotify?)

The main issue I see with this is that getting this robust when the
window manager newly manages a window is a little difficult since
the window manager doesn't know how many ConfigureNotifies the client
might have queued up; I don't see any way fixing this which is both
robust and remotely simple.

I'm wondering if it might make sense to have explicit synchronization
between the two streams; in essence, the window manager sends a
message to the client immediately before the action that triggers
the ConfigureNotify which says "after finishing processing from
the next ConfigureNotify, please update _NET_UPDATE_COUNTER to
<64-bit value>".

Leftover queued configures should be trivial to ignore with this 
scheme. There is more traffic here, of course, but I don't think
one extra client message and no round-trips per window resize should
be noticeable.

The only question here is whether having notification to the window
manager of spontaneous redraws not triggered by a resize is useful;
I don't see how it is without something like the Composite extension,
and I think this will have to be rethought a bit for the Composite
extension anyways.

Regards,
						Owen