[openbeos] Re: Tracker icons
- From: André Braga <meianoite@xxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 22 Jul 2005 11:23:40 -0700
2005/7/22, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> With lookup, I actually mean "is the attribute there?" I don't mean
> "read it" (which inherently includes a lookup, too).
Is it that slow? Won't the VFS vnode cache (assuming there is one!)
have all the atributes in RAM by then?
> 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.
Again, is it that slow? I suppose a failed attempt to extract an icon
is much worse than just testing for its presence. Again, assuming that
the VFS caches the vnode.
> True. Actually, when you said "icon cache" I didn't know you meant
> "cached on-disk icon".
As opposed to what? Now I got a little lost =/
> Why not? There are even use cases of this on BeBits (SVG clock via
> icon).
In this case, the application would better write straight to the icon cache.
> 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).
In this case, all that's needed is making the icon cache a system attribute?
> Simplicity should restrict us to certain formats.
IMHO simplicity would be reusing the existing data translators
infrastructure and, because of that, get considerable flexibility for
free.
> And "because we can" was never a good reason for me :-)
Showing off the OS' capabilities is always great :)
Isn't reusing code the whole point of having an OO API after all?
> 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.
I still like my "blessing of a couple official formats but allowing
users to do as they see fit" better. ;)
> And that got me confused. Sure, neither PNG nor SVG icons will fit into
> the small_data section in most cases.
Which is why I proposed an internal format Tracker would render the
icons into and potentially store into the small_data section. I called
it the "icon cache". See?
> Now it's my attitude? That's great - I'm just trying to have a
> reasonable discussion, really.
I'm really sorry, then. In your first reply to my post I thought your
language was a little rude. Which is not your regular attitude at all.
So this had upset me a little bit =/
> 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"
?! o_O ?!
w00t?!
I'm so confused by this that I even got curious on what (the hell!)
were you thinking :D Care to explain a little more?
> 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 :-)
I'll try to answer that if I eventually grasp what you had thought before ;)
> 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;
But it's only for the first time you ever access that file, and that's
the absolutely worst case. Then you'd just do a single lookup for the
rest of the file's life, on it's icon cache. You could even just copy
the legacy icon to the icon cache for kicks...
> 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.
That's what the MIME database is for, no? And in this case having the
icons on RAM is a better solution.
> No, that's not obvious, that's wrong. You still have to look, you just
> won't find anything.
By your definition of lookup, yes. I meant something different by "lookup".
> Having differently sized icon attributes is also already a bit more
> inefficient, because you have to lookup first once to get the size.
As opposed to what, rendering it JIT? Sorry, but I disagree.
> Definitely, though it didn't change my mind :-)
I always knew your opinions are hard to bend :D :D
Cheers,
A.
--
"A year spent in artificial intelligence is enough to make one believe in God"
-Alan J. Perlis
Other related posts:
