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.
_______________________________________________
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
