Review of the thumbnailer spec
Brian J. Tarricone
bjt23 at cornell.edu
Thu May 14 19:19:30 PDT 2009
Jannis Pohlmann wrote:
> This is exactly what e.g. file managers need though. Just imagine a
> file manager enters a directory, queues all its files for thumbnailing
> and then switches the directory before all files are processed by the
> thumbnailer. So IMHO it should be pointed out more clearly that this is
> not a violation of the spec. Right now it just says "You can't unqueue
> requests that are currently running." This should be something like
> "You cannot cancel the processing of individual URIs but thumbnailers
> are free to support cancelling running tasks between the processing two
> URIs when a task unqueued."
Why be so resrictive, though? For some image types currently-running
cancellation isn't feasible, but why explicitly disallow it? If the
thumbnailer can indeed interrupt an image decoder/encoder in the middle
of processing, why not do so?
Better would just be something like:
"Unqueue removes thumbnail requests from the queue. A service
implementation is only guaranteed to cancel requests that have not
started processing yet when it receives the Unqueue request. A service
implementation may cancel an in-progress request if possible, but
clients should not depend on this behavior being available."
The thumbnail server could still emit Finished on the item --
immediately if it was able to stop immediately, or later if it had to
wait for an in-progress request to finish.
I could see this being useful at least on the open/read side of the
thumbnailer. Even if you're using gdk-pixbuf, this could be implemented
by using a GdkPixbufLoader to incrementally load a file, with
cancellation points every XYZ kilobytes. For larger images (think 10MP
photos), this might be a nice thing to have on a slower machine, as
creating a thumbnail might take several seconds, or more.
Other cancellation points could be after loading but before scaling, and
after scaling but before saving.
You probably couldn't cancel many thumbnailers in the middle of scaling
or saving, of course.
> Another thing I noticed is that timestamps passed over D-Bus (e.g. the
> "since" argument to org.freedesktop.thumbnailer.Generic.Cleanup) are 32
> bit unsigned integers ("u") while they should really be 64 bit uints
> ("x"). Philip told me the reason to use "u" was that some D-Bus
> versions didn't handle "x" properly. On the long run there's no way
> around 64 bit ints though, I guess.
Is it really the case that 64 bit ints don't work with dbus in some
places? If this is just pre-1.0 versions of dbus, I don't think it's a
big deal. If it's dbus on certain platforms, then that might be a problem.
More information about the xdg