Re: Size allocation and redrawing issues

[Soeren Sandmann <sandmann daimi au dk>]

Owen Taylor <otaylor redhat com> writes:

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

What I meant was that size_allocate() should do

	if (HAS_ALLOCATION && (allocation == widget->allocation)
		return;
	else
		emit (size_allocate)

Essentially, HAS_ALLOCATION is a negated version of your NEED_ALLOCATION.
	
> > 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.

Well, yes, the real simplification would be in gtkcontainer.c.

The simplifications in gtkwindow.c would be because the
gtk_window_move_resize could just call gdk_window_move_resize() and
have gtk_window_configure_event() call queue_resize() instead of
calling size_allocate() to maintain complicated resizing
invariants. That is, if I read the comments in gtkwindow.c correct.

> 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

The reason I want to get rid of them is because they complicate
resizing and aren't really necessary, not because they would improve
performance. I agree that my suggestion is more work, and since the
two proposals are API compatible, the simplifications could easily
wait for 2.2.

Søren