[openbeos] Re: Tracker icons
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 22 Jul 2005 19:27:45 +0200 CEST
André Braga <meianoite@xxxxxxxxx> wrote:
> 2005/7/22, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> > > 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
With lookup, I actually mean "is the attribute there?" I don't mean
"read it" (which inherently includes a lookup, too).
> write, possibly delayed or done in a background thread.
> b) Case 2: only legacy icon. Use it. 1 test, 1 lookup.
You don't know that it only has a legacy icon, first you try the cached
icon, then the new style icon, and finally the legacy icon - that makes
3 lookups, no matter how you describe it.
> c) Expected case: the file has a cached icon. So use it! 1 lookup.
True. Actually, when you said "icon cache" I didn't know you meant
"cached on-disk icon".
> > 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...!
Why not? There are even use cases of this on BeBits (SVG clock via
icon).
> > 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.
I did, but I can't see how this makes this argument less of a problem -
if there is enough space in the small_data section, it will place the
data there, if not, it will be put to a separate file; BFS only prefers
system attributes over others, it has no understanding of user defined
attributes (like what MDR is doing).
> > Why should we do this?
> Simplicity, for one. And because we can.
Simplicity should restrict us to certain formats. And "because we can"
was never a good reason for me :-)
> > 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
Exactly, we should agree on those, and restrict the support to these
types - that's the only way to make sure that only those formats will
show up in icons. If we see the need, we could easily add some other
types over time.
> 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").
And that got me confused. Sure, neither PNG nor SVG icons will fit into
the small_data section in most cases.
> > 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.
Now it's my attitude? That's great - I'm just trying to have a
reasonable discussion, really. The reason for that maybe not so well
fitting comment was that I completely misunderstood you. If you like,
please reread your previous mail with "cache == living system that runs
in the background" in mind (unlike your "write rendered images to
disk"). Maybe I missed something, too, but I don't think that my
attitude was a problem if you read it that way :-)
> > 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!
Yes, but you always have to check for custom icons, even if they are
absent - and 3 lookups are just too much for this, as you have to do
this with every file; the "no special icon" case is the most common, so
you definitely have to optimize for that case first, and only then look
into the other performance bottlenecks.
> 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
No, that's not obvious, that's wrong. You still have to look, you just
won't find anything.
Having differently sized icon attributes is also already a bit more
inefficient, because you have to lookup first once to get the size.
> > Sorry, I can't agree.
> Did my explanation help at all?
Definitely, though it didn't change my mind :-)
Bye,
Axel.
Other related posts:
