Tumbler

Last few weeks I have been working on the new thumbnail infrastructure for future Maemo products.

Last year I made a specification for requesting thumbnails over D-Bus. Afterward I made a quick prototype and replaced the hildon-thumbnailer library of Maemo with it. This prototype will be deployed on the standard N900 image. It’s too late to replace Fremantle’s thumbnailer with the new stuff. It takes time to properly test it.

While I was developing both the specification and the prototype XFCE developer Jannis Pohlmann contacted me about rewriting my prototype for use in the XFCE project. Tumbler was born.

The nice people at Nokia are more interested in working with upstream projects instead of maintaining own products separately, so I shifted my focus from hildon-thumbnail to contributing to Jannis’ Tumbler project.

We realized that we needed different kinds of schedulers so while Jannis was developing Tumbler I kindly asked to consider abstracting scheduling a bit. Tumbler now has two schedulers. The background one sets I/O and scheduler priorities to IDLE and processes its thumbnail tasks in FIFO order. The foreground uses LIFO and will instead of grouping Ready signals together, emit them immediately after each single thumbnail is finished. Default is of course foreground.

We also realized that thumbnail flavors are going to be platform specific. So we added some support for this in the DBus APIs that we further fine tuned and versioned.

Congratulations and appreciation to Jannis who made Tumbler’s code and design really nice. Also thanks a lot for constructively considering our requirements and helping adapting Tumbler’s code to cope with them.

I know you for example worked one long night on this stuff, so I officially owe you a few beers and/or cocktails next conference.

How about FOSDEM?

7 thoughts on “Tumbler

  1. Zeeshan Ali (Khattak)

    Cool stuff! Since you are already working on all this, wouldn’t it be nice if you could try to sync your work with the existing thumbnailing in gnome or the other way around or both ways. :)

  2. Gustavo Sverzut Barbieri

    It does not any scheduler specific settings, but you might want to consider this project http://svn.enlightenment.org/svn/e/trunk/ethumb/

    it ships with an in process library and a client-server using DBus. It supports generating fdo-compatible thumbnails but also more extensions, like borders/frames and even animated thumbnails, like those used in http://profusion.mobi/node/17

    Of course it contains EFL-ism, like the animated thumbnail and frames, but maybe it’s worth considering. Also it’s a good comparison for generation speed, specially for large sets of png/jpeg using non-fdo. If you generate thumbnails from jpeg as jpeg it’s very fast.

  3. Jannis

    Oh, and @Zeeshan: That’d definitely be great. I don’t know how thumbnailing can be extended to support more file types in GNOME but e.g. for Xfce, I’m about to write a Tumbler plugin that supports ThunarVFS thumbnailer scripts (thumbnailer commands that are defined in .desktop files and write their output to a temporary file). If something similar can be done for GNOME, Tumbler could provide much of the functionality of the GnomeThumb(nail?)Factory class, except that it’s a global service, not a function executed in-process.

    One could also write a GObject class for calling the thumbnailer service. The level of control that applications need when requesting thumbnails varies strongly though. File managers need to do a lot of tuning (I did this in Thunar), while applications that only need a single thumbnail every once in a while could use the service in a much simpler way.

  4. Zeeshan Ali (Khattak)

    Jannis, Thanks a lot for your quick reply. Glad that we agree but I must admit that what I had in mind when I wrote my last comment was thumbnail storage: That would mainly mean the format (codec & size). The file extension will be implied of course since you won’t put .png in front of a jpeg file. :)

    If you don’t know already, I am interested in this because of my DLNA MediaServer (http://live.gnome.org/Rygel) and DLNA explicitly requires thumbnails to be in JPEG format and not exceed the size of 160×160 so hildon-thumbnailer works better for me than current gnome applications. That is why I would really love to see the gnome thumbnail specs to be changed to comply with your standards.

  5. Jannis

    Tumbler supports difference thumbnail storage backends. So it is possible to replace the XDG cache (png, 128×128 or 256×256) with something different (like Maemo does). This can be implemented as a cache plugin which is very simple.

    To avoid ambiguity, it only supports one cache backend at a time though. If an application requests a thumbnail, we can’t risk that it doesn’t know where to look for the final thumbnail after the request is finished. So we’re assuming that on each platform, one storage backend is used consistently. On deskop systems like GNOME and XFCE, this would be the XDG cache with PNGs in ~/.thumbnails/normal and ~/.thumbnails/large. All desktop apps look for thumbnails in those directories. On Maemo, thumbnails are stored as JPEGs and all Maemo apps look for those JPEGs instead of PNGs. Of course applications can be written to support both ways to load thumbnails.

    So for the media server situation this would mean that it has to run in a dedicated environment (with the cache plugin using JPEG) where all applications agree that JPEG is good. Mixing this with desktop apps might get you into trouble though unless the thumbnail managing standard is extended to support JPEG alternatively.

    If you have any ideas how to solve this in a better way, let me know. ;)

  6. Zeeshan Ali (Khattak)

    >unless the thumbnail managing standard is extended
    >to support JPEG alternatively.

    That is exactly what i am recommending. :) If you guys start the discussion on relevant mailing-list (or irc) please let me know and I can try to help you push for this.

Comments are closed.