-
Since large images are in the icon cache, and apps don't tend to use that many icons anymore, simply don't include image data and instead make apps load files from disk. Additionally, since they're stored in GdkPixbuf data, that means that we have to first convert them either to a cairo_surface_t, which requires converting pixel data to be premulitplied, or an OpenGL texture, which requires a whole GPU upload anyway. So, even with the icon cache, the goal of icons through zero-copy, mmap()'d data from disk just isn't doable with the icon cache format we have. The icon cache on my disk is nearing 100MB, since we include a bunch of high-resolution application icons, that I doubt would be used by apps at all. Removing this inefficient pixel data makes memory usage for all applications go down, with no speed loss. The icon cache also, however, has an index of what icons are in each folder, which prevents a readdir() and allows GTK+ to know what icon is where without having to do a bunch of stat(); calls. Keeping this data is good for GTK+, so we should still keep the index. It doesn't make sense to remove any code for mapping pixel data from the icon cache. There's a plan in the works to have a symbolic icon cache that does pixel math on 16x16 icons to prevent slow SVG rendering. 16x16 pixels are fairly small, and such images are flat colors, which should compress easily, so the icon cache would be worthwhile here. So let's keep the code around in preparation for that case. https://bugzilla.gnome.org/show_bug.cgi?id=721895
6f92c794
