Here’s a meme: org.freedesktop.Thumbnailer

People who know me probably saw this blog item coming. Here it is!

In Tracker we want to ahead of time create thumbnails for interesting files. Among the use cases is when the user has moved or copied photos from his camera into one of the photo folders. We want to start preparing thumbnails for those files early so that filemanagers and photo applications are fast when needed.

The current infrastructure for this in Tracker is to launch a script for each file that is to be thumbnailed. If you find a lot such files (some people end up with a camera with 1,000ths of photos after a busy weekend), that would mean that we’d do this 1,000 times:

fork();
execv(tracker-thumbnailer);
fork();
execv(bash);
fork();
execv(convert);

Luckily this is not activated by default in current Tracker. :-)

I don’t have to explain most people who read this blog that this is a bad idea on a modest ARM device with a bit more than one hundred MB of RAM. A better idea would be to have a service that queues these requests and that solves the requests with specialized image libraries. Perhaps launching a separate binary for the MIME types that the service has no libraries for?

At first we were planning to make tracker-thumbnailer listen on stdin in a loop. Then I figured: why not do this over DBus instead? Pretty soon after that was Ivan Frade concluding that if we’d do that, other applications on the device could be interested in consuming that service too. We decided that perhaps we should talk with the right people in the two large desktop communities about the idea of specifying a DBus specification for remotely managing the thumbnail cache as specified by the Thumbnail managing standard by Jens Finke and Olivier Sessink.

I don’t know of a official procedure other than filing a bug on freedesktop.org, so at first I tried to get in touch with people like David Faure (KDE), Christian Kellner (Nautilus), Rob Taylor (DBus, Telepathy, Wizbit) and later also a few mass discussions on #kde-devel, #nautilus and #gnome-hackers.

I started a discussion on xdg-list which made me conclude that such a DBus API would indeed make sense for a lot of people. Discussions with individuals on IRC added to that feeling. I started a draft of a first specification for a DBus API.

Meanwhile I had already started adapting the hildon-thumbnail code to become more service-like. Right now that code has a DBus daemon that implements the draft DBus API and on top of that provides the possibility to have dynamically loadable plugins. The specification also allows registering thumbnailers per MIME type. For that reason I made it possible to run those dynamically loadable plugins both standalone and in-process of the generic thumbnailer.

It has been my prototype for testing the DBus API specification that I was writing. People told me that if you want to make a specification that’ll get accepted, the best way is to write a prototype too. Meanwhile Rob Taylor had joined me on fine tuning the specification itself. With his DBus experience he helped me a lot in multiple areas. Thanks for caring, Rob!

The current prototype does not yet make it possible to simply drop-in a thumbnailer binary to add support for a new MIME type. By making a standalone thumbnailer that for being a thumbnailer simply launches external thumbnailers you could of course add that possibility that a lot of current thumbnail-infrastructure has. Although as mentioned above I don’t think this is a good architecture (the fork() + execv() troubles), I plan to make such a standalone plug-in thumbnailer.

I certainly hope that this specification will be approved by the community. I can help with making patches for Konqueror and Nautilus. We’ll most likely use this on the Maemo platform for thumbnailing ourselves.

9 thoughts on “Here’s a meme: org.freedesktop.Thumbnailer”

  2. Hi,

    Very much awaited feature ! Hope that Nautilus, Gtk+, etc. will take advantage of this asap !

    Regards,
    Étienne.

  3. Hopefully f-spot too, I don’t know what exactly it does right now but I’m sure it could benefit of such a service. If you let me know when your stuff is working I can try to patch f-spot.

  4. Thanks a lot for that promise, Johannes. I hope this meme becomes reality indeed, so that we can innovate the desktop and its many applications.

  6. The use case of thumbnailing as files are copied or created is an excellent one, and a great thing for Tracker to do! :)

    I also assume that if there is one central service, that when other applications that also do thumbnailing, like the file manager, can detect duplicate requests – if only by noticing that there already is a thumbnail created when the queue comes to that point. Scenario for this: when copying files, both file manager and Tracker could react simultaneously. This could, in a worst case scenario with separate code, mean that both tries to thumbnail them all at the same time.

  7. @Stoffe: in that case would the first create a thumbnail and would the second immediately return as it noticed that a thumbnail-cache is already available.

    With parallel handling (since it’s strongly recommended to make your service asynchronous, one could make a thumbnailer that handles in parallel), it’s of course up to the implementer of the thumbnailer to let the code make an intelligent decision about this.

    With a simple LIFO queue where active requests can’t be canceled and where only one thumbnail is being generated at the time, you don’t have the problem (the second queued item will just notice the cached thumbnail, and will immediately return).

    It could be useful for the thumbnailer to notice it in its queue (that another queued item is related to the current) and make the decision to instantly emit a `Ready` for both.

    The specification allows this, it’s up to the implementer of a thumbnailer to build-in this kind of internal intelligence in his thumbnailer implementation.

    Thanks for your suggestions.

Comments are closed.