Re: Size allocation and redrawing issues

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

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

This was a typo in my mail - I meant to say 'window widgets' here.
 
> > 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

OK, these still all hold true except for:
 
 queue_resize(parent);=> size_request+size_allocate+redraw on _immediate_
                         children

The immediate children of parent will only be requested if
size_request was done on them or their descendents, size_allocate only
if the allocation changed, and redraw only if the allocation changed
(or they are no-window widgets.)

I can't think of any reason anything would be depending on the
last.

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

Yep.

> >  * 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?

Yes, because the invalidation on size change in size_allocate() takes 
care of this.
 
> >  * 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?

Yes, once I actually made the patch, I got rid of the resize_widgets

> and, ALLOCATE_NEEDED implies size_request-needed i suppose?

It will be typically be the case since we set both at once
and almost always call request before an allocate. (The exception
would be if someone not in the GTK+ core called size_allocate() not 
from a size_allocate() handler ... which would be rather dubious)

> >  * 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?

Just the two areas. (gdk_region_union(), not gdk_rectangle_union())

Regards,
                                        Owen