Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

["Dr. Michael J. Chudobiak" <mjc avtechpulse com>]

On 09/29/2009 12:00 PM, Mark wrote:
> Well, the benchmarks ran above are resizing 1927 wallpaper sized
> images to a max width or height of 200 and that function clearly
> loses.
> The solution to this is extremely simple. Grab this file:
> http://git.gnome.org/cgit/gnome-desktop/tree/libgnome-desktop/gnome-desktop-thumbnail.c
> and replace the line:
>        scaled = gnome_desktop_thumbnail_scale_down_pixbuf (pixbuf,
> 						  floor (width * scale + 0.5),
> 						  floor (height * scale + 0.5));
> with a function that is (a lot) faster.


Mark,

Have you tried benchmarking changes to Nautilus, rather than your own 
benchmark program? (That was the original point of this thread, right? I 
forget now...)

My understanding of gnome-desktop-thumbnail.c is that the "problem 
function" gnome_desktop_thumbnail_scale_down_pixbuf is only called if an 
external script returns an over-sized thumbnail (e.g., like a video file 
returning the first frame). In most cases (such as jpegs and pngs) 
_gdk_pixbuf_new_from_uri_at_scale will be used to return a 
correctly-sized thumbnail instead, so the performance of 
gnome_desktop_thumbnail_scale_down_pixbuf is a non-issue.

_gdk_pixbuf_new_from_uri_at_scale should use the jpeg scaling trick (in 
the jpeg loader), followed by the gdk scaling routines (in the generic 
pixbuf io file).

Also, if you're playing with benchmarks, you might test to see if 
gnome_desktop_thumbnail_scale_down_pixbuf is superior when downscaling 
by huge factors (say, from 16000x16000 to 16x16). The code comments 
certainly imply that. The gdk down-scaling routines can blow up and 
freeze the system under these conditions.

Anyway, great to see someone looking at the issues... these are just my 
thoughts.


- Mike