Humanity theme slower than Gnome Adwaita

[Fabien Tassin]

While investigating why gnome apps are much slower when using the Humanity theme compared to Adwaita on Quantal (with Gnome 3.5.90), I noticed that the apps are re-loading the Humanity theme files over and over again, dozen times per second, when hovering icons. It's most noticeable with evolution, rhythmbox, gedit, just to name a few.

Try it yourself using strace, like strace -p $(pidof app) -f -tt -e open
and hover the icons (like in toolbars, or folder trees..)

The reason for those zillions read() is that Humanity is providing almost exclusively SVG files, but gtk-update-icon-cache(-3.0) is not caching SVG files at all, so GTK ends up re-loading them every single time a repaint is needed. This is really bad for I/O, and make the corresponding UI sluggish. I find it hard to believe it's not already known, yet i couldn't find an existing bug about this.

To verify this theory, i converted the theme to png with the attached debdiff (*not* to be sponsored), and now strace no longer shows those unexpected read(), and my whole desktop feels faster.

The resulting deb is of course bigger (9.1MB compared to 2.9MB)

This automatic conversion is not perfect though, some icons seems mismatched (like places/16/folder.* used in the folder pane in evolution, which is not the same size when it's focused (the grey folder icon)) but i did it to have an idea of the speed improvement, if any, which in my case proved real and very noticeable.

The real fix would probably be to teach gtk-update-icon-cache* to cache SVG files. In the meantime, a PNG Humanity would be welcome.

(1) Some details there: https://bugzilla.gnome.org/show_bug.cgi?id=681877#c11
(which also shows private icons need to be cached by their app)