Re: Standardizing _METACITY_UPDATE_COUNTER

[Lubos Lunak <l lunak suse cz>]

Dne so 21. února 2004 16:51 Owen Taylor napsal(a):
> 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

 I only reviewed the patches, so it's possible I miss some technical details 
about this issue, in which case please forgive me and enlighten me.

[snip]
> > 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.

 I don't. Resizing that feels bad may be a somewhat unpleasant thing, but it's 
still much better than resizing that is bad. And I don't think anybody would 
like resizing done in 3 second steps, just because the application cannot 
keep up. The KWin patch has a timeout, and if the application can't keep up, 
it does another resizing anyway.

> 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?)

 Good luck with detecting which ConfigureNotify events to ignore and which 
ones not. The ICCCM doesn't require sending synthetic event if the client 
gets real one. On the other hand, WMs may simply send both, at least KWin 
does that because of some buggy apps (Tk IIRC).

> 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>".

 Hmm. Could somebody please explain to me why this actually has to use XSYNC 
counter? I might be wrong, but it seems to me that the KWin patch actually 
doesn't check the value of the counter, it simply stops the timeout and does 
another move/resize when it gets notification about counter update. I 
remember I wondered a bit about this, but it makes sense to me:

1) the WM does a resize, and sends ConfigureNotify
2) the WM times out, and repeats step 1), possibly repeatedly
3) the client compresses ConfigureNotify events, does a redraw, and tells the 
WM that it's ready for another resize
4) the client repeats step 3) once more because of event(s) from step 2)
5) goto 1

 The ideal case of course includes only steps 1), 3) and 5). In the worse 
case, which includes all the steps, the client will be at most one incomplete 
redraw lagging behind the WM, which is actually not bad at all, because the 
app has to finish all redraws anyway (unless you want to implement some 
redraw aborting), and the variant not having this problem has the IMHO much 
worse 3-seconds-steps problem I mentioned above. All this perfectly possible 
to do with ConfigureNotify going one way, PropertyNotify on some property 
going the other way. So what's the point of the XSYNC counter that I fail to 
see?

> 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.

 As I understand this protocol, it's only for syncing when doing user 
moving/resizing. So I don't see any reason for the client sending the updates 
to the WM on redrawing that has nothing to do with user moving/resizing.

-- 
 Lubos Lunak
 KDE Developer