Re: Nautilus thumbnail creation SLOW. gThumb does a much faster job.

["Iain *" <iaingnome gmail com>]

On 4/10/07, Mark <markg85 gmail com> wrote:

> i just opened up some directory`s with thousands of images and i saw that
> nautilus is horrible slow.
> gThumb on the other hand seems to be extremely fast.
>
> i mean.. nautilus seems to use imagemagick now to create the thumbnails and
> that might be a little overkill to just generate thumbnails. imagemagick can
> be used for so much more and all that stuff is (in this case) a waste of cpu
> cycles.
> I do wonder how gThumb does this but it looks like they are just using
> gdk-pixbuf url:
> http://developer.gnome.org/doc/API/gdk-pixbuf/
> so.. please CONSIDER rebuilding the thumbnail generation part!! it will go
> alot faster.

If you check http://svn.gnome.org/viewcvs/nautilus/trunk/libnautilus-private/nautilus-thumbnails.c?revision=12726&view=markup
you'll see no mention of imagemagick, and that it uses gdk-pixbuf.

Now I do notice an interesting possible slow down in this code though
at line 587 the thumbnailer walks through the list of thumbnails to
check that the new thumbnail isn't already scheduled for creation, and
then it walks the list again at line 595 to append schedule the new
thumbnail. With a few thousand entries this could slow it down a
little. Would having a hashtable that stores scheduled thumbnails as
well as in the list help any? Maybe storing the end-of-list pointer so
appending thumbnail to the list is O(1) instead of O(n)

It also has to loop through this list to remove the item from the list
at various places (such as line 427), although if the list is FIFO
then that won't be a problem. We could however hold a pointer to the
thumbnail's list member in the hashtable so that removing it would be
O(1) as well.

Would this help speed up thumbnailing with large directories?

iain