Re: Standardizing _METACITY_UPDATE_COUNTER
- From: Lubos Lunak <l lunak suse cz>
- To: wm-spec-list gnome org
- Cc: gtk-devel-list gnome org
- Subject: Re: Standardizing _METACITY_UPDATE_COUNTER
- Date: Sat, 21 Feb 2004 21:20:21 +0100
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]