Proposed draft for the thumbnail D-Bus specification
Philip Van Hoof
spam at pvanhoof.be
Tue Sep 9 09:43:16 PDT 2008
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
More information about the xdg