Re: Standardizing _METACITY_UPDATE_COUNTER
- From: gtg990h mail gatech edu
- To: wm-spec-list gnome org
- Cc: gtk-devel-list gnome org
- Subject: Re: Standardizing _METACITY_UPDATE_COUNTER
- Date: Sat, 21 Feb 2004 14:35:21 -0500
sandmann daimi au dk writes:
> The reason Havoc's patch, as it stands, should not be applied to gtk+
> is that it makes gtk+ increment the counter every time gtk+ finishes
> drawing. Of course, gtk+ will draw when one of its windows is resized
> by the window manager, but it will also draw in other situations, eg.,
> because an animation is running.
I do not know how GTK+ handles resize events, but in theory, the Qt patch
should not have this behavior. It only increments the counter after a
ConfigureNotify event has been completely handled. This works because Qt's
ConfigureNotify handler compresses all ConfigureNotify events in the queue, and
then pulls all Expose events off the queue, compresses those, and then finally
does the draw. So the Expose handler doesn't have to be touched at all.
<snip/>
> So one-to-one is the only possibility. Note that the application
> can still (and should) compress multiple ConfigureNotifies and handle
> them all at once. In that case it should send a "COUNTER += n"
> message, where n is the number of compressed events.
One-to-one should be the policy, but I don't think it should count compressed
events. During a resize, a complete "update" is the result of some number of
ConfigureNotify and Expose events. We want to keep the window manager
synchronized with how fast the window updates, not necessarily how fast it can
handle individual events. Incrementing the counter multiple times during an
update will cause the window manager to try to resize the window faster than
the app can handle complete updates.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]