Re: Icon theme scalability ...

[Michael Meeks <michael ximian com>]

Hi Owen,

On Fri, 2003-05-16 at 14:49, Owen Taylor wrote:
> 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 :-)

	Hmm ;-) simply because icons are not per-se visible doesn't mean (to
me) that they are not fully loaded; eg. menu layout / sizing, even
gnome-terminal with a hidden menu-bar manages to do scads of pango init,
measure all it's strings (and pixmaps?) before not showing any of them
;-) the more icons in your menus, perhaps the worse the problem;

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

	My oowriter has: ~43 toolbar icons, ~41 menu icons and ~27 navigator
icons.

> 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.

	Fair enough; my only concern is that the API allow this kind of
caching; and is not (as the exisiting mime API (AFAIR)) a char
*get_file_name_for_icon (); type API; it seems far better to be
returning const GdkPixbuf * references.

>  - 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

	This includes all the mime icons at several sizes. My feeling is that
Mime icons should be at in a separate category to menu/toolbar icons at
some level. It also seems to me that either my maths is very faulty, or
'du' includes slack file space in it's accounting - making it rather an
interesting metric. [ I get a du -b of 8192 for a single 782byte png
file + 2*4k blocks ? ].

	It seems to me that the ~1Mb(du) of 16x16 and 500k(du) of 24x24 icons
(BlueCurve/16x16/actions, BlueCurve/24x24/stock): 264 and 122 icons
respectively could easily be built into two ~300kb flat files; with an
ordering based on frequency of usage; with a mmaped into (and thus
shared between) gtk+ processes - and raw pointers returned inside
GdkPixbufs. 

>  - 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.

	So we have a chance to speed up login time :-) I agree though it would
be profitable to be able to propagate some finger in the air locality /
frequence of reference information into the ordering.

>  - 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.

	The seek time argument works because the OS should read more than a
single 4K page in from disk; even so a 4K page contains 4 16x16 icons,
and ~2 24x24 ones; which is a significant reduction in seeking.

	Anyway, I'll shut up now - it's mostly an API issue - that we don't
work at the 'filename' level.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot