Re: Icon theme scalability ...
- From: Michael Meeks <michael ximian com>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk Hackers <gtk-devel-list gnome org>, Alex Larsson <alexl redhat com>
- Subject: Re: Icon theme scalability ...
- Date: 19 May 2003 10:19:38 +0100
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
> 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
> - 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.
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
] [Thread Prev