Re: Muffling widget repaints

[Stephen Bach <9sjb qlink queensu ca>]

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.