Re: Size allocation and redrawing issues

[Tim Janik <timj gtk org>]

On 24 Oct 2001, Owen Taylor wrote:

>  * There are some optimizations that we are missing. For example,
>    if you are resizing a toplevel, it should not be necessary to redraw
>    no-window widgets that don't change size.

don't change size _and_ position.

> The important things that must be maintained:
> 
>  * If you call gtk_widget_queue_resize() on a widget, that must result
>    in:
>   
>     - a call to gtk_widget_size_request() on the widget
>     - a call to gtk_widget_size_allocate() on the widget
>     - the widget being redrawn
>   
>    Currently, all three of these will propagate to descendents
>    of the widget, but I don't think there is actually any real
>    requirement that the second two propagate (except as required
>    by changing allocations, and propagation of exposes to NO_WINDOW
>    children.)

urm, i know some containers/children make use of that
propagation knowledge. basically, they can assume (for resize containers):

queue_resize(child); => size_request+size_allocate on parent (though
                        size_allocate only happens if the parent grew),
                        size_request+size_allocate+redraw on child
queue_resize(parent);=> size_request+size_allocate+redraw on parent,
                        size_request+size_allocate+redraw on _immediate_
                        children

>  * By default, if a widget is allocated with a different size,
>    we must invalidate all of the new and old allocation in
>    widget->window and any descendent windows owned by the widget.
> 
>    We do not need to invalidate in descendent windows not 
>    owned by the widget.

unless those descendants changed size of course, but the size_allocate()
on this widget's children shoudl handle that.

>    It may be desirable to add a widget flag to turn off this behavior.

> The scheme I have for achieving the first three goals while maintaining
> the above facts (some of the stuff below is already done, but included
> for clarity.)

>  * In gtk_widget_queue_resize(), invalidate the allocation of the widget
>    in widget->window and all descendent windows owned by the widget.

if it grows, the newly gained areas are also being taken care off?

>  * Use the following algorithm in gtk_container_resize_children():
> 
>     Set a private ALLOCATE_NEEDED flag for all widgets in 
>      resize_widgets, and all intermediate widgets between those
>      widgets and the container.
> 
>     Call gtk_widget_size_allocate() on the container.

erm, what do you keep a resize_widgets list for then?
simply propagating up ALLOCATE_NEEDED to the resize container
would be sufficient, no?
and, ALLOCATE_NEEDED implies size_request-needed i suppose?

>  * In gtk_widget_size_allocate():
> 
>     Clear the allocate_needed flag.
> 
>     If the allocate_needed flag was not set and the new allocation is
>      equal to widget->allocation, return.
> 
>     Call size_allocate() on the widget
> 
>     If the allocation->x,y changed and its a NO_WINDOW widget, invalidate
>     the union of the old and new allocation.

union meaning outer rectangle of the two areas, or just the two
areas?

>     If allocation->width,height changes:
>       If redraw_on_allocate is not set:
>         Invalidate difference of old and new allocation in widget->window
>         if it's A NO_WINDOW widget, otherwise do nothing
>       Iif redraw_on_allocate is set:
>         Invalidate the union of the old and new allocation in widget->window
>         and in all descendents of widget->window owned by the widget.
> 
>  * On map and unmap:
> 
>     If the widget is NO_WINDOW, invalidate the widget's allocation.
> 

---
ciaoTJ