Re: finishing update counter patch

[Soeren Sandmann <sandmann daimi au dk>]

Havoc Pennington <hp redhat com> writes:

> > There is no reason to wake up the window manager on every single
> > update, and in fact doing so could be harmful. Consider a window with
> > an animation in it; the animation will make gdk send a continuous
> > stream of update notifications making the window manager think the
> > application has handled the ConfigureNotifies when it hasn't.
> > 
> > So I think there should be a one to one correspondence between
> > ConfigureNotifies and update notifications.
> 
> That's not right though - you don't want the counter to bump on
> receiving a configure notify, you want it to bump after you've
> repainted - which we do in an idle, compressing multiple
> configurenotify. If you did N bumps if there were N configure notify
> before the idle, I'm not sure I see the point of that. What does it
> gain you? Doesn't it in fact break things? (metacity would send N new
> configure notifies in response to the N bumps...)

Metacity as it is now would not send N configure notifies in the first
place (it would wait until it saw a bump, then send a new configure
notify, then wait ...). So it wouldn't break with metacity.

Bumping N times (note that you don't have to actually send N bumps,
you can just send "Counter += N") would allow the window manager to
keep track of where the application is in the configure notify stream,
which seems like a useful thing, like the serial numbers on X
events. I can't think of any concrete application though.

> If there's an animation while the WM is not resizing the window, then
> the WM can just ignore the counter; no reason it even has to request
> counter events while not resizing. If there's an animation during
> resize, then anytime the toolkit finishes a full repaint it's a
> reasonable time to move on to the next resize increment, so there's no
> problem with an extra counter increment I don't think.

It is only reasonable to move on to the next event if you know that
the application has actually _seen_ the last configure notify you
sent. If the application sends updates at random times, you can't know
that.

> GTK would compress the animation steps into the idle, just as it
> compresses the multiple configure notify, right?

Gtk+ will push everything to idle, so it may not be a big problem in
practice there, but in principle the problem still exists:

        WM sends configure notify
        [gtk+ hasn't seen configure notify]
        gtk+ sends update because the animation changed
        WM sees update
        WM sends another configure notify
        [gtk+ still has not idea about configure notifes]
        gtk+ sends update because the animation changed
        WM sends another configure notify
        ...
        [gtk+ finally sees configure notify]
        gtk+ size allocates, draws and sends update

> >   - What happens if the window manager tries to reference the update
> >     counter after window has been destroyed?
> 
> This is the WM's problem - WMs standardly have to push error traps
> around all attempts to access client-provided resources.

Ok.

Sørn