On Fri, 2004-04-23 at 23:41, Michael Meeks wrote: > Hi Mark, > > On Fri, 2004-04-23 at 17:22 +0100, Mark McLoughlin wrote: > > - loading the icon theme information (35%) > > => Owen has a proposal that should go some way towards fixing this: > > > > http://mail.gnome.org/archives/gtk-devel-list/2004-April/msg00065.html > > If we're going to go this far - why don't we go with more of a > fontconfig type approach, that is done on a per-system basis; thus > saving first-time/space in users' home directory. Please reread my proposal. It's not in the user's home directory, it's in the top of each theme directory or directory full of icons. Putting caches into the user's home directory is essentially broken for, e.g., NFS mounted home directories and I don't think it's worth supporting. > Also - if we're going to have this file - please, please, please can we > include the icon data: > > http://mail.gnome.org/archives/gtk-devel-list/2003-May/msg00073.html > > Note particularly the warning about facile du -b usage. > > Since I wrote that, various discussions have convinced me that having a > const char *buffer in a GdkPixbuf pointing directly into the mmaped data > has not only excellent seek/load properties, shares the memory across > processes etc. etc.[1] - but also behaves nicely under memory-pressure, > since the kernel can page that stuff back out to file, and read it again > chunk-wise instead of jumbling memory page-by-page into swap. I'm not sure you are really taking raw/expanded into account properly in your response. And if we end up going to SVG icons you can't have the GdkPixbuf with the pointer to mem-mapped data. But as I said before, I don't have a gut feeling for whether adding a 4M+ file full of image data mapped into every GTK+ program is a win or not. I do know that currently we are using a lot more memory and startup time for the icon index than for the image data. So that was my primary concern. In the end, the details of the format are largely under the control of the person who actually has time to implement it. And at the moment, that isn't me. > Anyhow - since I can't measure / prove this is a large speedup (except > by inspection), I'd only ask that we have an easy-to-check header flag / > space in the format for expansion somewhere to add this in future; is > that reasonable ? Well, make a proposal about how you would do it. You might want to make ImageList be a list of offsets, rather than having the images contained directly, or, to avoid too much non-locality for icon lookup, you might just want to *add* an offset to what's already there. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part