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@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
