Re: GNOMEPrint, Icons, and shades of InSight..

[Bowie Poag <bjp primenet com>]

> Well, you should at least finish your thought.  (c:  Was there a _problem_ you
> ran into at Insight?  Was it too much work?  Or did the scaled icons just look
> bad?  With Gleef's scheme, each size would have its own separately-drawn icon,
> so scaling isn't a problem.  And it'll only be done once, for the single foot
> icon (or if it becomes themable, then the themed replacements, too), and then
> we'll never have to worry about it again.
> 
> What made multiple icon sizes unworkable at Insight?  At least tell us that
> much.

Hehehe.. Thanks for asking, John.

The problem was two fold, with using multiple icon sizes.. Keep in mind,
InSight and GNOME were built very differently. We were literally trying to
build an OS that nobody would want to use in 1998 -- But would be suitable
for use in 2000-2001, when the hardware upon which it was supposed to run
would have been on par with very, very high-end machines today... Soo, we
didnt concern ourselves much with the fact that a typical InSight machine
was slated to need 64-96MB of RAM, and about the speed of a Pentium II or
better.

Well, thats beside the point. Lets talk about the feasability issues I
mentioned.

InSight was to have come pre-equipped with four sets of 256 icons. Each
set was kinda like a different style. So, grand total, you had 1024 icons
to more or less encompass everything you would need an icon to do. 

These icons were drawn at 64x64, and drawn specifically with the intent
that that would be scaled down, or up -- So, much attention was payed to
retaining detail when going from 64x64 down to very small sizes (16x16).
If an icon was drawn that was NOT readable at 16x16, it was tossed, and
the icon redone.. So it was important that we had a good scaling engine to
make it worthwhile.

Basically, after much, much, much thinking (about 3 months, every night or
so, live... This would equate to about a year and a half here on the
mailing list) we arrived at a conclusion as to how to go about doing
things. A material archive would be set up, as part of the OS.. Literally,
just a directory where icons are stored, and organized according to set,
type, and size. Again, all of them began at 64x64. If the user wanted to
change the size of his/her icons to 32x32 (whichever ones they were
using), the original 64x64 would be scaled down to that resolution, and
cached out, back into the archive for future reference.

The problem we ran into was, that after X amount of time, that archive was
going to grow. I remember doing the math, and coming up with some kind of
outrageously high storage requirement for the cache, if we were to allow
arbitrary values to be used for how small the user wanted the icons to be.
Ontop of which, if the user chose a size who's shape was not a factor (or
the median between two factors) the scaling engine would produce a crappy
looking icon.. So, the perfect comprimise was met:

  Do not let the user specify arbitrary values for the icons. Restrict
  them to choosing values in multiples of 8 pixels, to prevent the
  scaling engine from generating ugly icons.

So, now, we had only a handful of icon sizes to be concerned with, which
by and large eliminated the storage space worries we had for the archive,
and in doing so, assured the user of having good looking icons. A very
elegant comprimise.

This is why its a bad idea for the (foot) icon to be on the menu bar with
text. Text is something you WANT to have exacting control over the size
of. 7 point, 8 point, 9 point, 10 point, whatever. You cant really do the
same thing to icons without incurring the wrath of Ugly Icon Syndrome. The
best scaling engines in the room will produce a crappy looking icon if the
icon isnt A) Bilaterally symmetric, and B) Scaled to a resolution which is
a factor of, or a MEDIAN between two factors of the original dimensions of
the source image.

Bowie

PS.. Youre talking to the guy who had to paint 1100 of them for InSight.
Trust me on this one. :)