Re: finishing update counter patch

[Havoc Pennington <hp redhat com>]

Hi,

Thanks for the followup.

On Sun, Jun 08, 2003 at 08:48:01PM +0200, Soeren Sandmann wrote: 
> I don't think the counter should be an "update" counter. Rather, it
> should be a ConfigureNotify counter. 
> 
> 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...)

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.
GTK would compress the animation steps into the idle, just as it
compresses the multiple configure notify, right?

What I think the WM is really interested in is "every time the window
is in a fully-redrawn state" not "every time a configure notify has
been received"

> Questions on the patch itself: 
> 
>   - Don't you need to check for a destroyed window in
>      _gdk_window_must_notify_updated()?

Probably so.

>   - 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.
 
> I don't think it's a good idea for gtk+ and metacity to start making
> up "standards" that aren't documented anywhere and "can always change
> later". In my opinion the hint should be added to the spec before
> going into gtk+.

To me the issue is whether they really can always change later.  In
this case, I see no reason this particular thing can't change later;
nothing will break at all if GTK stops having a
_METACITY_UPDATE_COUNTER hint on its windows.

Of course I'd rather have it in the spec, but really, there is no
interoperability or ABI issue I see if it isn't.

Havoc