Re: Size allocation and redrawing issues

[Owen Taylor <otaylor redhat com>]

Soeren Sandmann <sandmann daimi au dk> writes:

> Owen Taylor <otaylor redhat com> writes:
> 
> > Could you please review the following: it describes some things I'd
> > like to improve with allocation and redrawing, gives a list of
> > "invariants" that I think we need to maintain, and proposes a few
> > changes to the way we do allocation and redrawing.
> 
> What I would do for size negotiation is
> 
> 	- add two private flags, GTK_HAS_ALLOCATION and
>           GTK_HAS_REQUISITION, meaning that the values in
>           widget->allocation and widget->requisition are correct.
> 
> 	- queue_resize redraws the widget non-propagatingly and clears
>           the flags HAS_ALLOCATION and HAS_REQUISITION all the way
>           from the widget to the toplevel inclusive. Then it sets the
>           flag RESIZE_PENDING on the toplevel widget and installs an
>           idle handler that will size_allocate the toplevel widget.
> 
> 	- size_allocate and size_request do not emit their signals if
>           the HAS_REQUISITION and HAS_ALLOCATION are set. If the
>           signals are emitted, the flags are set.
> 
> This would mean that a queue_resize would result in a complete
> size-renegotiation of the widget-tree, but the HAS_* flags mean that
> only widgets that must actually change have the signals emitted on
> them.

Well, the HAS_REQUISITION flag should work and may well be a
worthwhile additional optimization to my proposal, but the
HAS_ALLOCATION flag doesn't. Just because a widget hasn't changed it's
size request doesn't mean it won't be allocated a differnet
size. (Make the toplevel bigger, grow another child, etc.) :-)

> This is much simpler than the current system. A lot of code could be
> deleted from gtkcontainer.c and also some from gtkwindow.c, because
> the resizing invariants would be much simpler to maintain. This system
> also completely ignores the resize_mode on containers, but resize_mode
> is not of much use anyway, and the caching of requisitions and
> allocations should make it completely unnecessary.
> 
> This system is probably somewhat more work to code and debug, and it
> involves depreceating gtk_container_resize_mode.

I doubt there would be much simplificiation to gtkwindow.c, since
that code isn't concerned with the children of the window, all
that code is in GtkContainer.

I don't think getting rid of the size modes would actually improve
performance any or be easier to implement (that is, removing them
would be something extra to do as compared to my proposal or to adding
HAD_REQUISITION) though, as you say, the performance benefits of
GTK_RESIZE_MODE_QUEUE are probably negligable if you remember
requisitions and don't reallocate widgets when they don't change size
or position.

(GTK_RESIZE_MODE_IMMEDIATE has always been an extraordinarily bad idea.)

> >  * 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.)
> 
> In my suggestion, gtk_widget_size_request() doesn't propagate into a
> subtree if that tree doesn't contain a widget that had
> gtk_widget_queue_resize() called on it. Is it necessary for
> size_request() to propagate always?

No, it's not. As I say above, it's only necessary when
gtk_widget_queue_resize is called.

                                       Owen