Re: synchronizing window frame/client repaint

[Soeren Sandmann <sandmann daimi au dk>]

Havoc Pennington <hp redhat com> writes:

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

Here is an example:

Suppose you have a GtkWindow containing a GtkFrame containing a
GtkHbox containing a GtkVbox containing three buttons. Assume the vbox
is not set to expand to fill the vbox and that the buttons are also
not expanding. Then when you resize the window, those three buttons
stay in the same position inside the window.

If GtkWindow and GtkFrame were !redraw_on_allocate, those three
buttons would not be invalidated, because their size allocation
wouldn't change and gtk+ caches size allocations. The only reason they
are invalidated currently is that GtkFrame and GtkWindow invalidate
their entire allocation, even areas where they don't intend to draw
anything.

If the GtkFrame became !redraw_on_allocate, its size_allocate should
just invalidate the old and new areas covered by the shadow, not the
child area.

Of course, the "three buttons" could be an arbitrarily complex widget
tree.

This example is not contrived. You could easily imagine a side bar
that

        - didn't contain any !NO_WINDOW widgets
        - didn't change (horizontal) size when the main 
          window was resized
        - contained expensive drawings, like pixbufs 

The savings would be

        - less CPU time spent by gtk+, because it would have to
          traverse a lot less widgets doing exposes. (I believe I
          measured that 60-80% of a resize cycle[1] is spent doing
          exposes after we added size allocation caching).

        - fewer drawing requests are sent to the X server, so the X
          server would have less to do

Note that these savins would be per mouse event, so the result would
be that gtk+ would be able to handle a lot more ConfigureNotify per
second.


Søren