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

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-04-11 at 15:00 +0100, Iain * wrote:
> On 4/10/07, Mark <markg85 gmail com> wrote:

> 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.

It uses gdk-pixbuf, which has special case code for quick scaling of
jpegs. However, what it doesn't do is read thumbnails embedded in jpeg
files. Maybe this is what gthumb does?

> 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?

I doubt it would make a noticable difference except in enourmous
directories, but it probably wouldn't hurt.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a short-sighted ninja grifter who dotes on his loving old ma. She's a 
wealthy junkie snake charmer married to the Mob. They fight crime!