Re: Standardizing _METACITY_UPDATE_COUNTER

[gtg990h mail gatech edu]

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.