[gtk-list] Re: gtk_container_check_resize performance

[Shawn T Amundson <amundson cs umn edu>]

I played with this a little more and determined it had nothing at all
to do with buttons, because it is almost as slow with just labels.  I
have the labels in a table, so "42 labels in a table results in slow
performance when updating the 42 labels" is more accurate that I had 
described before.

My temporary work around (until a better solution hits me) is to hide
the table (after putting a box around it so it doesn't resize), do the
updates, and then show it again.  This is fast, but does cause
an unwanted "flash" and is still too slow to do with buttons. (I'm 
testing with only labels now, and buttons draw slower obviously.)

I've tried to figure out a way to say "don't mess with this table
widget" and then later say "do all that messing now".  In other words,
prevent screen updates until a specified time.  In TK this is done
automatically until it gets back to the event loop unless you tell 
it to update.  Can a similar thing be achieved here?

-Shawn

P.S. To something said before:  The documentation that is written
so far for gtk is excellent, in my opinion.

Words Of Raph Levien:
>
>Like Shawn Amundson, I have run into performance issues with
>gtk_container_check_resize. What really slows things down is adding
>widgets dynamically to a container that is already mapped and visible.
>
>   Basically, every time a new child gets added, the whole tree gets
>recomputed and redrawn (I think). I'm not sure what's the best solution
>to the problem. My best guess is to try to defer the redraw until after
>all widgets have been added (say, by taking a trip or two through the
>idle loop), but it's not clear to me how to do this.
>
>   This is a problem for gzilla because the HTML page is a container and
>all of the images, form thingies, and tables are widgets inside. All
>these widgets get added whille the page is displayed because of
>progressive rendering.
>
>   Now that the gtk_container_check_resize logic has displayed both
>correctness and performance problems, it may be time to rethink it.
>
>Raph
>
>--
>To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>


--
Shawn T. Amundson		University of Minnesota
Systems Administration	 	Computer Science System Staff
amundson@cs.umn.edu	  	http://www.cs.umn.edu/~amundson/     	

I'm fairly convinced that when God drinks beer, he drinks Guinness.

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