A Standard for Thumbnailers

Erlend Davidson E.R.M.Davidson at sms.ed.ac.uk
Thu Jan 11 04:35:37 PST 2007


On 11 Jan 2007, at 10:25, Benedikt Meurer wrote:

> Stanislav Brabec wrote:
>>>> Haw widely used desktop-neutral thumbnailing library  
>>>> understanding many
>>>> embedded thumbnails and providing thumbnailing for images without
>>>> embedded thumbnail.
>>> I think external thumbnailer as used by Thunar/Nautilus are better,
>>> because it's more flexible and avoids loading various libraries  
>>> required
>>> to generate thumbnails for different formats into the processes.
>>
>> External binary thumbnailer has to initialize and load needed  
>> libraries
>> again and again for each image. If you will have library, you can  
>> manage
>> this better by using shared modules. For example you can load them on
>> demand and unload after finishing of thumbnailing of the directory.
>>
>> For typical small and simple thumbnailer it saves only few  
>> milliseconds
>> per image, for thumbnailers preloading larger libraries it may be  
>> more.
>
> There are very good reasons to avoid this. You don't want to load
> arbitrary code into the file manager (or any other process) just to
> create a thumbnail. See Alex' for good reasons to avoid this.
>
>> From the performance POV, we're talking about milliseconds,  
>> because it
> doesn't really matter whether ld loads the shared libraries into our
> process or into a new process. It's basicly the fork overhead, plus  
> some
> additional setting up (but since thumbnailers, except for the very  
> basic
> ones, will usually not benefit from previously performed file manager
> initialization, except probably g_type_init() to use GdkPixbuf, this
> doesn't take much time).
>
>>> Using .desktop files to register thumbnailers instead of GConf  
>>> should be
>>> fine for desktop-neutral usage.
>>
>> I agree. Additionally GConf has no way to solve more-thumbnailes-per-
>> MIME-type problem (later wins), desktop files can solve it (by  
>> mechanism
>> of choosing defaults).
>
> So, we're back on-topic. ;-)
>
>>>> Thumbnails can use file system extended attributes.
>>> Not every file system supports that. What would be stored in the
>>> extended attributes anyway?
>>
>> If file system has extended attributes, maybe you can use them to  
>> store
>> thumbnail. I am not sure about xattr limitations, but Apple's HFS  
>> uses
>> something similar called resources to store thumbnails.
>> If file system does not support it, the fall back to other methods.
>
> This will work on certain platforms, but not on Linux, so you won't
> benefit from it. Because the size of the xattr block is limited to  
> a few
> hundred bytes (while I'm not sure if it also applies to other file
> systems or only ext3).

Well, if we want to store thumbnails local to each individual mount  
(as the parallel discussion on this list is suggesting, for security)  
then extended attributes would definitely be out - camera flash cards  
all use the FAT filesystem.

I don't even have extended attributes support in my kernel - I don't  
know how common it is.



More information about the xdg mailing list