Re: synchronizing window frame/client repaint

[Havoc Pennington <hp redhat com>]

On Sat, Dec 21, 2002 at 02:13:49PM +0100, Soeren Sandmann wrote: 
> [Havoc:]
> > > Bit gravity never helps
> > > with GTK for example, and I would expect the same with Qt.
> 
> Maybe I am misunderstanding you, but gtk+ does make use of bit
> gravity. The TreeView in 2.2 resizes significantly faster than that in
> 2.0 because of bit gravity. If you unset the redraw_on_resize flag,
> only the "uncovered" corner of a resized widget is scheduled for
> redraw. The rest of the widget is left alone. The reason we can do
> that is bit gravity.
> 
> It is often the case that a widget does not move within its window
> (whether or not it "owns" that window). Making more aggressive use of
> this fact will reduce both gtk+'s CPU consumption (fewer widget to
> call "expose" on) and the amount of input gtk+ feeds to the X server.
> 

I guess what I mean is, I don't see how we can use bit gravity across
the widget tree. The TreeView is a single subwindow that it knows
everything about, so it can try using it, but for a GtkWindow as a
whole, I don't see how you can do much with bit gravity; any window
resize will redo all the size allocations.

And in general we've been killing off subwindows, as they have plenty
of disadvantages, along with this advantage.

Havoc