Re: Size allocation and redrawing issues
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, blizzard redhat com
- Subject: Re: Size allocation and redrawing issues
- Date: 03 Nov 2001 08:44:26 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]