Re: finishing update counter patch



Havoc Pennington <hp redhat com> writes:

> The way the patch currently works is that it increments the update
> counter:
> 
>  - anytime we process updates
>  - in an idle after receiving a configure notify 
>    (normally we'd process updates before the idle runs, 
>     I think is the idea, but we need to guarantee 
>     we update the counter even if no updates get processed)

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.

Questions on the patch itself: 

  - Don't you need to check for a destroyed window in
     _gdk_window_must_notify_updated()?

  - What happens if the window manager tries to reference the update
    counter after window has been destroyed?

> Right now this patch is metacity-specific, but I think it's worth
> putting in anyway. Can always change it later, it's not anything
> that creates ABI or that needs to be frozen. There wasn't any
> initial interest on wm-spec-list in adding the hint to the spec.

There weren't any objections either. 

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


Søren



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]