Re: Muffling widget repaints

[Todd Fisher <toddf simosoftware com>]

Hi,

This sounds like a very similar problem I'm having.  I'm curious if you 
have some test case code that you could
post?

thanks,
Todd

Stephen Bach wrote:

> I've come up with an acceptable solution to my problem, which I'll post here
> for posterity.  First my observations:
>
> - The expose signal for the container was emitted only once, and after all the
>  widgets had been added/removed.  This is good and means GTK is being smart,
>  and that gdk_window_freeze_updates() wouldn't help me.
>
> - If I left the container showing, a changeover involving 2000 widgets took
>  about 30 seconds, with X cpu usage hovering at about 85% and the program's
>  cpu usage at about 15% (i.e. all of it).  During the switchover, I could
>  see widgets in the container shifting periodically, but the container never
>  fully redrew itself during the switchover (and expose-event was not
>  emitted).
>
> - If I hid the container immediately before the changeover and showed it
>  directly afterwards, the changeover took only about 3 seconds, and X cpu
>  usage only seemed to reach about 40% and the program's about the same.
>
> Eventually I found that most of the processing was because of (or related to)
> size negotiations.  The container received size-request and size-allocate
> signals for each widget added/removed.  Since only the final
> size-request/size-allocate pair was relevant, I took out the
> gtk_widget_queue_resize() calls from the pack and remove functions of the
> container.
>
> This worked great for the removal, but for the packing I'd still get the size
> negotiation thrashing as soon as I gtk_widget_show'd the new children
> (whether I did so before adding them or after they were all added).  So I
> connected to the size-request signal of the container and added a condition
> to prevent signal propagation if it was during a switchover.
>
> This works okay -- it takes about 8 seconds for a changeover.  Certainly
> there's a more complete solution, and hopefully something a little more
> elegant (insight welcome), but it'll do for now.
>
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
>