[gtk-list] Re: gtk_container_check_resize performance

[Raph Levien <raph acm org>]

On Sat, 10 May 1997, Peter Mattis wrote:

> You can call "gtk_container_disable_resize" to disable automatic
> resizing of the container when a new widget is added. Calling
> "gtk_container_enable_resize" turns automatic resizing back on and, if
> a widget has been added or removed, will cause the container to
> resize. 

It works! This is a fine solution for now.

One performance issue for later (right now I'm focussing on getting 
everything to work) is to make sure to redraw only the new widgets. This 
is possible because the HTML layout rules are incremental: adding a new 
widget at the bottom (which is the only place a new widget can be added) 
does not cause any change to the widget at the top. Thus, if a new widget 
is added off the bottom of the viewable area in the scrolledwindow, there 
should be no painting at all.

> I think I'll look into doing something like Tk does. Install an idle
> proc when a container needs to be resized inorder to defer the actual
> resizing until the events in the queue have been flushed. (Idle procs
> only run when there are no events).

In the long term, this may be a better solution. Doing the 
gtk_container_check_resize with a NULL widget causes the entire 
containter to be painted, whereas doing it the Tk style may allow you to 
queue up only the widgets that need work. There could be quite a few 
gotchas in this approach, however. For example, if a widget is deleted 
from the container, it needs to be deleted from the queue too.

I also see that container_check_resize with a NULL widget causes a 
gtk_widget_draw with a NULL rectangle, which in turn causes a draw signal 
with the container's entire allocation area. For a big Web page, this 
could be bad.

I haven't thought this through carefully enough, but I think the right 
approach might be to make modifications to the size_allocate machinery. 
Specifcally, I don't think it's necessary to call the size_allocate 
method of children if they haven't moved or changed size. In the html 
container, most of the time widgets won't have moved or changed size. I 
experimented with simply making gtk_html_size_allocate return immediately 
if the allocation hasn't changed. That did improve performance 
considerably, but I'm not sure of its correctness.

BTW, can anyone explain to me the rationale for why a widget should or 
should not have its own window? It is obvious why a viewport should be a 
window (a cheap call to XMoveResizeWindow gets the window scrolled), but 
far less clear why a button needs to be a window. For the time being, I'm 
using ifdefs so I can configure the html container to have its own window 
or not. So far, I can't see any difference, but when I start heavily 
nesting them (because that's how tables are going to work), it will 
probably become more significant.

Raph

--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null