Stanislav Brabec wrote: >>>> BTW: I fail to see the problem here. How often do people regenerate >>>> thumbnails that +1 or 2 seconds for 40 JPEGs makes a difference? >>> It's important because it gives an impression of slowness and >>> unresponsiveness. And you rarely generate them, but you import pictures >>> from digital cameras rather often. >> Here the I/O is definitely the limiting factor from my experience. >> Accessing data on digital cameras is very slow with the models I've tested. > > No, for digital cameras the limiting factor is the stupidity of the > thumbnailer. > > Small jpeg-EXIF-embedded thumbnail is most often stored in first few > blocks of the image. You can create thumbnail much faster than you can > load the image. > > Mid-size jpeg thumbnail (typically 640x480) is typically stored in last > few blocks of the image and you need only few additional seeks to find > exact start point. You can again create thumbnail faster than to load > image. > > You can try to compare my dcraw-thumbnailer with Nautilus jpeg > thumbnailer to see the difference: > http://www.penguin.cz/~utx/gnome-dcraw > Note that this page also contain "classical" thumbnailer, which reads > the whole file and scales it down by its own.
Can we perhaps use this trick for the dcraw thumbnailer? Jens/Erlend? Benedikt _______________________________________________ Thunar-dev mailing list [email protected] http://foo-projects.org/mailman/listinfo/thunar-dev
