Re: Standardizing _METACITY_UPDATE_COUNTER

[Owen Taylor <otaylor redhat com>]

On Sat, 2004-02-21 at 15:20, Lubos Lunak wrote:

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

I think you are missing the point here; the question here is being able
to tell reliably whether the changes resulting from a given resize that
the window manger did have been done.

With Havoc's GTK+ patch this isn't possible at all, since the app may
spontaneously update the counter due to an event unrelated to a resize.

With the Qt patch (though I haven't read it), it sounds like the only
way to do it is for the window manager to always wait until the app
responds before sending another configure. If you time out and send
multiple configures, then you can't tell the difference between

Resize, <timeout>, Resize (compressed) update
Resize, update
Resize, update


And:

 Resize <timeout>, Resize update, update
 Resize, update
 Resize

So we don't reliably know whether the last Resize has been processedor
not. If we reliably have one increment per ConfigureNotify, then 
this situation is unambiguous.

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

 - There is a field in the event which says whether it is synthetic or 
   not.
 - The *app* will get a real ConfigureNotify for every resize of the
   window; that's just how X works.

So if you only care about resizes, ignoring synthetic ConfigureNotify
is easy and fine. I don't have trouble 'acking' synthetic
ConfigureNotifies as well, but:

 - The spec should specify that the app does explicitely.
 - The spec should give an implementation hint that the window manager
   should move the window *before* sending the synthetic ConfigureNotify
   so that the expose events from the move have already been sent
   to the application. Otherwise, the notification does no good.

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

The protocol could just as well involve a client message the client
sends to its own window or the root window, really. XSYNC got involved
mostly it was designed for similar situations and has basically
the right primitive objects, but it isn't essentially involved here
since blocking on counter values with XSyncAwait() isn't useful for a
window manager.

Note that using client messages is distinct from the question of whether
using a serial or counter in the protocol makes sense.

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

If there is a counter or serial in the protocol a PropertyNotify means a
round-trip to get the value contents, which would be nice to avoid. 
(Which is why I mention a client message above)

You can actually think of an XSYNC counter as being vaguely like
a property holding a 64-bit counter where the PropertyNotify includes
the new value of the counter...

Regards,
						Owen