On Tue, 2008-09-09 at 18:25 +0200, Jakob Petsovits wrote: > On Tuesday 09 September 2008, Philip Van Hoof wrote: > > No, your application (the library on top) must take the > > best-fit thumbnail and do a final resize instead. > > Hm, that's two resizes in the case of images - first time you resize down > from > the original image to the thumbnail-specified size, and then you resize > *again* from the thumbnail-specified size to the displayed size. > I can see three clear disadvantages with that approach: > > - Unnecessary performance (= battery) issues, obviously > - Resizing from a small, already-resized image looks just terrible > - Plus you can't really do plaintext previews with tiny fonts (like present > in Konqueror for KDE 3) because you must assume that resizing the > thumbnail makes it unreadable. > > That imho defeats all quality requirements that can be demanded from a > thumbnailer (bad image quality, unreadable text) unless you use the exact > specified sizes. There must be a better way to do that, no?
Well, the thumbnail-spec allows to put nearby sizes in either large or normal (but for normal "not larger than x"). That puts the decision at exactly *one* process: the one that makes it the first time. Which means you might as well just let your specialized thumbnailer make the decision instead of the desktop application! >From an architectural point of view, it makes no difference who decides about the size (the specialized thumbnailer or the application). Except that if the application needs to make the decision, that this bleeds through the entire specification (for no good reason, as in the end it's the specialized thumbnailer who can internally override the final decision anyway - and still be 100% correct by spec -). The point of thumbnail-spec is to do caching of thumbnails that are a lot smaller, and always locally-available, than the originals. So to get to your point (text files): For text-files, just make a specialized thumbnailer that makes thumbnails of the preview-text at the max size of the thumbnail-spec. That's, I think, 256x256 for large and 128x128 for normal (I need to check, not sure). If your viewer wants a ultra-high quality thumbnail, it shouldn't use neither thumbnail-spec nor thumbnailer-spec (the DBus one being specified). Because by spec, neither of the two can give you that. Instead, it should just make its own ultra-high quality thumbnail and perhaps do its own caching in its own cache directory. The point is that if there wouldn't be any agreement on thumbnail sizes, and everybody would require ultra-high quality thumbnails, then what would be the point of caching anyway?? You can't provide it. Instead, you agree on a common size, and you cache that. Which is what thumbnail-spec is about. Who makes the detail-decision (what the *exact* *exact* size will be), is up to only "one" entity. Best to make that entity the specialized thumbnailer instead of "some random application" (just because it happened to be the first to request the thumbnail). Poor applications that happen not to be the first ... $(Race race race conditions)++ How do you know, if you are not the first, that the thumbnail is a good one? Are you going to remove it and rewrite it? Why do any caching if apps are going to be silly and do that??? See? Recursive FAIL. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
