GNOME Bugzilla – Bug 687911
Focused/Unfocused theming applied slowly
Last modified: 2012-12-28 13:17:00 UTC
On Gnome 3.6 when moving the focus from the empathy chat window to the contact list window, it takes about 1s to change the theme on the contact list window (from unfocused to focused. If you try to click back and forth between these 2 window and look at the CPU consumption through top, the empathy process (which manages the contact list window) appears to consume 98% of cpu (vs just 20% for the empathy-chat process). If I disconnect one of my jabber accounts (which has about 80 contacts), then the performances become acceptable again.
Indeed, it's pretty slow here as well. I suspect that's the code changing the widget look when unfocussed which isn't playing nice with EggListBox or something.
Created attachment 228463 [details] [review] Add big contact list test case Focus in/out this window used to take a lot of CPU. See https://bugzilla.gnome.org/show_bug.cgi?id=687911 The dummy row widget code is copied from empathy-roster-contact.c to make the test more realistic.
Created attachment 228465 [details] Callgrind logs when doing a focus in/out I'm reading that file with kcachegrind. It looks like all of the CPU goes into calculating the width of widgets.
Analysis: Slowness is caused by all widgets changing style when going to the unfocused state causing style_update() emissions on all widgets. Plus: GtkLabel: always clears all PangoLayouts on any style change even if it doesn't affect the layout (i.e. a color change) => 1000s of PangoLayout measures is slow. GtkImage: Always clears the pixbuf on any style change => reloads the icon files 1000s of time, which is slow
Isn't the contact list a GtkTreeView?
@Lionel: not anymore, it is now using EggListBox which is probably going into GTK at some point. It's much nicer API, it's just a vbox basically :-)
I can't see any font size change on the contact list, only a color change. It should be possible to optimize that case to avoid relayouting. When you create a GtkImage with a given GdkPixbuf, the theme shouldn't clean the pixbuf since it's not related to the theme anymore. Are these optimization realistic?
Created attachment 228489 [details] [review] Use a pixbuf cache
Here is an attempt to workaround the problem in the test case. It indeed makes things faster, but still not perfect IMHO. With that patch, the size calculation related functions are down to 2% of CPU. But now it is _gtk_style_context_validate() which takes 88% of the time, which is less surprising since changing the style context is what it is supposed to be doing.
Created attachment 228490 [details] The new callgrind logs
Created attachment 228491 [details] screenshot of the interesting part of callgrind
I pushed some optimizations to gtk git master to make this somewhat faster. Its still as slow for images/labels though.
Created attachment 228546 [details] Self contained test case Here is a test case program that uses only GTK and not EggListBox. It has a boolean to switch on image cache hack to demonstrate that it speed it up a lot already.
This is working much better in Gtk+ master, as i spent a bunch of time optimizing CSS matching.
*** Bug 687536 has been marked as a duplicate of this bug. ***