Re: Icon theme scalability ...

[Owen Taylor <otaylor redhat com>]

On Fri, 2003-05-16 at 05:29, Michael Meeks wrote:
> Hi Owen,
> 
> On Thu, 2003-05-15 at 23:44, Owen Taylor wrote:
> > A surprisingly difficult part of the icon theme code ...
> 
> 	Which reminds me; one of the things that I would very much like to see
> in the gtk+ design is icon collections of some sort; it's horribly
> inefficient and a terrible idea to have your icons scattered all over
> the disk in lots of tiny files, of the order ~400 - 800 bytes each.
> 
> 	What we currently have seems to scale ~fairly well - but I would
> suggest this is because gtk+ is only used in 'small' apps. Having worked
> on OO.o and with the prospect of another ~600+ distinct new themable
> icons arriving shortly (~an order of magnitude increase) - it seems to
> me that we are going to need something that will scale to icon-bundles.

It doesn't seem to me that the *number* of icons being used at once
will go up that much ... there is a limit to how much you can fit on 
screen at once, even with OOo's habit of having lots of little cryptic
icons tucked into odd corners :-)

Looking at ooimpress, I see 38 icons on the initial screen; gnumeric
has ~45.

> 	The simple seek time penalty of fetching ~600 scattered icons can
> approach 6 seconds - particularly on a laptop; quite without the pain of
> the umpteen map/unmap/read kernel overhead for each

I haven't really thought about packing image *data* into cache files.
I've definitely have been thinking about ways to cache indices of cache
files to:

 A) Avoid a lot of readdirs at app startup time
 B) Be able to map the indices read-only to avoid memory overhead
    in each process. (I think the image caches can be ~64k)

Would it be possible to put the data into the cache? Yes. It might
even be a good idea, but I'd like to see some benchmarking.

Possible issues/questions:

 - Do you store the data as the raw PNG or XPM or in expanded
   form? (For SVG's, it clearly has to be raw.) Expanded
   form means that you don't have to copy the data even to use
   it, but it's probably prohibitively big. Even in PNG form:
 
    $ du /usr/share/icons/Bluecurve    
    13076   /usr/share/icons/Bluecurve
 
   raw form would be roughly twice as big.

 - Because data is getting read of disks in 4k chunks, it's likely
   that a large portion of the icon theme is going to be read in
   at login time even when not needed because icons don't pack
   nicely into pages and aren't going to be sorted as to whether
   they are actually needed.

 - Since pages in the icon bundle/cache aren't accessed sequentially
   if you mmap it, I'm  not sure that the seek time argument is
   valid. All you've done is created a filesystem within a filesystem.

Regards,
                                            Owen