[openbeos] Re: Tracker icons
- From: André Braga <meianoite@xxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 22 Jul 2005 10:09:45 -0300
2005/7/22, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> André Braga <meianoite@xxxxxxxxx> wrote:
> > What's wrong with creating another attribute for "new generation"
> > icons, and just leave the "legacy" attribute as a fallback in both
> > cases it's needed (too small a scale to gracefully downsample vector
> > graphics, and applications which don't support the "new generation"
> > icons)?
>
> Many things are wrong with this approach:
> 1) you need two lookups for every file you come across
Unless I'm overseeing something...
Assuming we're talking about Tracker, there are three cases:
a) Worst case: first access to that file, and it has a new generation
icon, which hadn't been cached yet. The image will be extracted,
converted, saved into the cache*. The converted image will be used.
Except from the (*), I guess it's not different from what the Zeta
tracker does today with SVG icons. 1 test, 1 lookup, and 1 attribute
write, possibly delayed or done in a background thread.
b) Case 2: only legacy icon. Use it. 1 test, 1 lookup.
c) Expected case: the file has a cached icon. So use it! 1 lookup.
> 2) new and old icon might easily get out of sync, say Net+ as an
> example - which one should Tracker show? The one Net+ is updating or
> the new style icon of that file?
I REALLY doubt that you're going to update SVG icons (for example) on
the fly...!
2 cases: if the application is going to use icons a means of
notification, either it's going to use the legacy icon (for speed) or
it will first get the user preferences to see his preferred icon size
for that folder and write straight to the cache.
> 3) as François said, the more data you pack into the attributes, the
> more likely it is to fall out of the small_data section, and thus it
> all gets even slower
Please, read my post on that remark.
> Why should we do this?
Simplicity, for one. And because we can.
> Why should people who haven't installed the
> brand new XYZ image translator see any icons on their desktop anymore?
I hope people agree upon a least-common-denominator format for
distributed applications or file formats, like PNG or SVG. The idea is
that nothing should prevent me as a user to have some image thumbnail
be based on the same format the image itself is. Or maybe this is a
bad idea afterall and we should standardize on PNG for bitmaps and SVG
for vector art. In both cases, it's still highly unlikely that any of
those formats (the SVG one SURELY WON'T) would fit on the small_data
section. Hence the need for some other attribute which would hold the
relevant data in some suitable format (and I chose to name it "icon
cache").
> Oh great, just another lookup, just some more space wasted in the
> small_data section of the file.
Dude, you're not following me at all... I could have expressed me in a
not-so-clear manner, but, really, your attitude won't help this
discussion.
> A cache can hardly speed up opening
> directories with lots of files in it, can it? A cache only makes sure
> that those icons in the MIME database are available translated on
> demand, and usually after the first lookup only, because icons use
> memory, too.
Weren't we talking about CUSTOM icons?! You would have to read up the
custom icons anyway!! What I chose to call "icon cache" is a
pre-rendered form of the either arbitrarily large bitmapped custom
icon or the vectorial icon that must be rendered anyway!
If there ain't no custom icons and the "generic" ones are on the MIME
database, no need for any lookups at all! That's obvious! Of course it
helps if you pre-render them (if needed) in the preferred user size
and leave it wherever you wish, be it in some custom attribute in the
MIME database or in-memory only. Your call. My suggestion was with
regards to CUSTOM icons.
> Sorry, I can't agree.
Did my explanation help at all?
--
"A year spent in artificial intelligence is enough to make one believe in God"
-Alan J. Perlis
Other related posts:
