The GTK icon cache conspiracy

Gullible Jones · 2012-05-07 03:08:21

I've wondered for a while why GTK (both 2 and 3) seem so slow even on (relatively) powerful computers.

I've also wondered why stock Slackware is very responsive... And why it is equally slow to boot.

Turns out all those things are connected. GTK uses a cache file that helps it access icons. Keep the cache updated with gtk-update-icon-cache, and GTK wil be fast. Do not use the cache, and it will be slow.

Slackware solves this by running the cache updater on boot. Especially with Slack's completely non-parallel init system, this slows things down a bit, but makes for a very response Xfce desktop.

Most other major distros... Don't seem to deal with this. Debian and Fedora at least do not, and I'm pretty sure Ubuntu doesn't either.

That's reasonable for a DIY distro like Arch, or if you're running a server without X. Otherwise, though, I have to wonder what gives, because users will definitely be left wondering why their desktop is slower than Windows 7 on the same hardware. Why not e.g. package a cache-updating script for desktop users, and run it as a daily cron job? Heck, why not package it as an initscript? Slackware's initscripts do nothing in parallel, but most desktop distributions boot quite fast, and that shouldn't be compromised by updating the icon caches.

Is there any particular reason why nobody (other than Pat Volkerding and company) does this as part of a default desktop setup? Other than that it doesn't help KDE and Qt applications, perhaps?

drcouzelis · 2012-05-07 03:17:40

I just updated my cache, thanks to your recent post in the other thread.

Is this something that needs to be done every boot, or only when changing something (changing themes, adding new icons)?

Gullible Jones · 2012-05-07 03:27:43

Only when changing or adding icon themes, AFAIK.

Edit: also, if you don't have any cache files to start with, you probably need to use 'gtk-update-icon-theme -f' to force the generation of caches. Otherwise no new caches will be generated.

Last edited by Gullible Jones (2012-05-07 03:31:29)

sitquietly · 2012-05-07 03:31:57

Gullible Jones wrote:

...GTK uses a cache file that helps it access icons. Keep the cache updated with gtk-update-icon-cache, and GTK wil be fast. Do not use the cache, and it will be slow.
...Is there any particular reason why nobody (other than Pat Volkerding and company) does this as part of a default desktop setup? ..

I've been wondering about this myself. I compile everything from source and my build scripts run namcap on every package that I generate. Namcap is smart enough to complain about packages that contain gtk icons and don't call gtk-update-icon-cache (namcap seems to be pretty darn good). After reading GJ's question I checked my build script and found that I've left myself this note:
# Quite some packages install icons in the hicolor icon theme.
# These packages should depend on hicolor-icon-theme and should have
# gtk-update-icon-cache -q -t -f usr/share/icons/hicolor (WITHOUT leading slash)
# in the post_install, post_upgrade and post_remove function.

I've been doing the cache update manually.

Does anyone know of a reason that the Arch packages do not have a call to gtk-update-icon-cache in a post_install function? Obviously our packagers see the namcap complaint when they check their packages so I suppose that there might be some reason for not doing the update as part of the install, but I don't know of any reason to avoid it.

brebs · 2012-05-07 07:22:28

Gullible Jones wrote:

Debian and Fedora at least do not, and I'm pretty sure Ubuntu doesn't either.

Yes they do. Debian/Ubuntu do it via package manager hooks - not exactly sure how, but in Ubuntu I see it run. Edit: If my memory is not playing tricks on me, it gets deferred until the bundle of packages have been updated - which is quite neat.

Empathy Fedora example.

With Arch: Do a git checkout of Arch packages. Then:

~/distros/arch/packages$ find -name \*.install | xargs grep gtk-update-icon-cache | wc -l
540

Example for Arch.

So which distros are you SURE of, that don't run gtk-update-icon-cache?

Last edited by brebs (2012-05-07 07:27:36)

Gullible Jones · 2012-05-07 13:40:09

The Fedora one you linked to only does it for the hicolor theme. It looks to me like that may be the only one that normally gets a cache created.

Last edited by Gullible Jones (2012-05-07 13:40:28)

brebs · 2012-05-07 14:05:09

Gullible Jones wrote:

only does it for the hicolor theme

That's the only one needed, the vast majority of the time. An exception is gnome-icon-theme:

gtk-update-icon-cache %{_datadir}/icons/gnome &>/dev/null || :

sitquietly · 2012-05-07 14:46:25

On my Arch system I grepped my local repo PKGCHECK files (output of namcap for the package) to find packages that seemed to lack the call to gtk-update-icon-theme:

firefox-kde-opensuse/PKGCHECK:firefox-kde-opensuse E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
frescobaldi/PKGCHECK:frescobaldi E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
gpodder/PKGCHECK:gpodder E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
hicolor-icon-theme/PKGCHECK:hicolor-icon-theme E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
imagination/PKGCHECK:imagination E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
qjackctl/PKGCHECK:qjackctl E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
qtractor/PKGCHECK:qtractor E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
razor-qt/PKGCHECK:razor-qt E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
v4l-utils/PKGCHECK:v4l-utils E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
videocatcher/PKGCHECK:videocatcher E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache

It's a fairly short list actually. Most Arch packages seem to update the cache properly:

clementine/clementine.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
dconf/dconf.install:    gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
dia/dia.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
djvulibre/djvulibre.install:  if [ -x usr/bin/gtk-update-icon-cache ]; then  
djvulibre/djvulibre.install:    gtk-update-icon-cache -q -f usr/share/icons/hicolor
emacs/emacs.install:  gtk-update-icon-cache -q -t -f ${ICON_PATH}
emacs/emacs.install:  gtk-update-icon-cache -q -t -f ${ICON_PATH}
flashplugin/flashplugin.install:    gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
geany/geany.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
genius/genius.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
glade/glade.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
gnome-disk-utility/gnome-disk-utility.install:    gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
gnome-icon-theme/gnome-icon-theme.install:  gtk-update-icon-cache -q -t -f /usr/share/icons/gnome
gnome-icon-theme-symbolic/gnome-icon-theme-symbolic.install:  gtk-update-icon-cache -q -t -f /usr/share/icons/gnome
google-chrome/google-chrome.install:    gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
gparted/gparted.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
gparted/gparted.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
gpodder/gpodder.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
gpodder/gpodder.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
handbrake/handbrake.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
jokosher/jokosher.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
meld/meld.install:  gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
roxterm/roxterm.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
sawfish/sawfish.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
sawfish/sawfish.install:    gtk-update-icon-cache -q -t -f usr/share/icons/hicolor 
xarchiver/xarchiver.install:  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor

Notice that namcap complained that gpodder and handbrake had "no call to gtk-update-icon-cache" but they do have the update in their install scripts, which their pkgbuilds fail to use properly

The funniest failure is the hicolor-icon-theme package itself: if fails to update the hicolor icon cache!

kuraku · 2012-05-07 19:01:52

Strange that you didn't noticed this before. It must be that you use stronger pc than mine (1.7GHz 32bit from 2002 here with 512MB of ram at that time). Also, i developed many icons and sets in the past (i believe that none of them ever came online since i used them only localy). I will try to write something about this so you can understand much more about icons and how they work. My english is bad and i'm lazy to correct all errors so pay no attention to them

Cache helps to gather all info about sizes in icon sets and all other attributes (where to put arrows etc). Many people just install or extract icon sets and dont give a lot of thinking about set itself. The real problem is in type of images used for icons. You can get SVGs and make your set stretch in all sizes. In theory, that means that 32x32 set can be defined only once in icon set index and apply that to all sizes on your screen.

So what is the problem then? SVG's looks better to develop and easier to manage. Well, the problem is that vector icons are drawn on your screen whenever you use them: when you start your file manager, when you get new message and icon in try changes or when you see new notification about XX program on your desktop. Here is cache coming to rescue. You can use it to reduce resource usage on your computer and therefore, the whole DE will be faster to load stuff on your screen.

Now, in gnome2 era, i used it for some time and i tested almost every release. I developed there and i tried to find out as much as i can about icons since i used them and i loved them (i still do). The problem with SVG sets was that there was no good developers who really understood the point of icon index files and icon development process. Tango set was the best thing that happened in that field. In short, Tango used raster icons in 16, 22, 24 and 32 sizes (sizes are in pixels). They left 48px version in SVG format thus they enabled for 48+ sizes to stretch to 512x512 if you wanted. They, however, limited sizes in index so they made 16px icons appeared only on places where 16x16 icons are supposed to show: in places where 16x16 icons have 16x16 space for icon. So, if sys tray had 16x16px space for icon, tango used (as defined in index) 16x16 version of icon and only that size. That is why Tango icons looked so crisp on well configured systems and DE's.

The problem with sizes was in developers and their desire to draw pure SVG sets in only one size. So we got many sets with 48x48 vector format in that gnome2 era. By rules, you can use 48x48 vector or raster images for any size so 48px icon could be used for tray that can use only 16x16px icons. SVG enabled that and rules in indexes allowed us to mess up with all that. Today we got some amazing sets like elementary where developers actually learned about how to effectively create icons and how to make them small thus fast when you use them in DE's. Back in the gnome2 era, we had a mess in this field. Then we got many forks of Tango, gnome-colors, erectus, gnome default set (latter, they used Tango guidelines) and other good sets that learned that sets can be very pleasant and fast.

The only thing that could speed up all this was to convert all images to raster ones. Raster icons allows you to use them and minimize sys resource usage and drawing process on screen. If you have slower pc, you can try to compare sets in vector and raster versions. Try older elementary set in SVG format and then convert all those icons to raster ones and try again. Raster set is faster? A lot? No wonder when you used fixed images and applied good rules in index of set. Your system now does not have to bother with rendering vector imags since you gave icons that:
- does not have to be rendered;
- are defined in index and therefore system will apply rules in certain cases.

Today great example of good set that uses all the goodies is Faenza. Faenza gives you smallest sizes in raster versions up to 48x48 sizes. Most people use 48x48 in file manager (nautils use them by default), 24x24 in toolbars and 16-24px icons in sys tray. So Faenza covered all popular sizes in raster versions.

So imagine what would happen if you use raster set with good index rules and with icon cache... I use icons this way for years and i had no slowdowns ever in any DE (have in mind that i'm reffering here to part of DE that is used for icon drawing on screen).

Gullible Jones · 2012-05-07 19:33:53

Yeah, I do have a more powerful computer - Asus Eee 1005HAB with a gig of RAM. I would guess that's more powerful anyway.

But I notice the difference even on my other machine, an Aspire 3680 (Celeron M 520 and 1.5 GB RAM). Especially on that machine, actually. With all the icon caches updated, it's a bit like the difference between a fresh Windows XP install and one with 6 month's worth of temporary files on it.

kuraku · 2012-05-07 21:11:35

There is difference on any computer. This could be less visible only on newest computers with a lot of power but i think that we should use as little as possible resources to display something trivial as icons.

Did you tried to use raster only icons?

karabaja4 · 2012-05-12 18:36:59

Can someone figure out why I can't seem to create a icon cache?

~ >>> gtk-update-icon-cache -f
gtk-update-icon-cache: No theme index file in '(null)'.
If you really want to create an icon cache here, use --ignore-theme-index.

~ >>> gtk-update-icon-cache -f -t
gtk-update-icon-cache: Failed to open file  : No such file or directory

Gullible Jones · 2012-05-12 20:36:39

You need to run it on the directory containing the icon theme.

Ikem · 2013-11-07 21:23:14

Gullible Jones wrote:

GTK uses a cache file that helps it access icons.
Keep the cache updated with gtk-update-icon-cache, and GTK wil be fast. Do not use the cache, and it will be slow.
...
Most other major distros... Don't seem to deal with this. Debian and Fedora at least do not, and I'm pretty sure Ubuntu doesn't either.

On Debian/Ubuntu everytime you install an icon theme a dpkg trigger is caused and the icon cache gets updated.

Last edited by Ikem (2013-11-07 21:23:32)

fukawi2 · 2013-11-07 22:07:35

Ikem, please leave the dead to rest in peace: https://wiki.archlinux.org/index.php/Fo … Bumping.22

Closing.

Arch Linux

#1 2012-05-07 03:08:21

The GTK icon cache conspiracy

#2 2012-05-07 03:17:40

Re: The GTK icon cache conspiracy

#3 2012-05-07 03:27:43

Re: The GTK icon cache conspiracy

#4 2012-05-07 03:31:57

Re: The GTK icon cache conspiracy

#5 2012-05-07 07:22:28

Re: The GTK icon cache conspiracy

#6 2012-05-07 13:40:09

Re: The GTK icon cache conspiracy

#7 2012-05-07 14:05:09

Re: The GTK icon cache conspiracy

#8 2012-05-07 14:46:25

Re: The GTK icon cache conspiracy

#9 2012-05-07 19:01:52

Re: The GTK icon cache conspiracy

#10 2012-05-07 19:33:53

Re: The GTK icon cache conspiracy

#11 2012-05-07 21:11:35

Re: The GTK icon cache conspiracy

#12 2012-05-12 18:36:59

Re: The GTK icon cache conspiracy

#13 2012-05-12 20:36:39

Re: The GTK icon cache conspiracy

#14 2013-11-07 21:23:14

Re: The GTK icon cache conspiracy

#15 2013-11-07 22:07:35

Re: The GTK icon cache conspiracy

Board footer