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.