[Digikam-devel] [Bug 132047] Faster display of images and/or prefetch wished for

[Brad Templeton]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=132047         




------- Additional Comments From kdebug mail 4brad com  2006-08-08 22:44 -------
Thanks.   My personal taste is I want gimp or other such tools for my true editing, and from my photo organizer I want to edit captions, tags and albums most.  Though of course many people do minor edits in photo organizers.  (Rotate is not so much an edit, since to be lossless for jpeg it usually involves re-reading the file.)

However, I come to digikam mainly for organizing, and it has the potential to be the best at that.   Right now the main barriers are the various beta bugs and crashes (since I am using the 9-beta1-2) which will of course go away, and the speed.   I have a number of other things I would like ( http://ideas.4brad.com/archives/000189.html ) but I think speed is the key missing element.

When I refer to rendering, I mean the decompression of the jpeg, what the editor is doing when it says "loading" with a status bar.  That (and also the scaling down to the planned viewing size) can be done in a background thread for the predicted next picture.   Then when it's time to display, a foreground thread w ould send the graphics to the X-server.   (Though on many displays now it is possible, I believe, to send it in advance to a hidden area, and then reveal the area for a truly instant display.  That's more important for slideshows than image management.)

If you've tried out kuickshow/pho/xzgv you will have seen how much faster they can move from one picture to the next, without pre-fetch.  If you try out gqview, you will see it's not as fast on the loading but does the pre-fetch.

RAM, as we know today, costs about $70 per gigabyte.  8 megapixel images require 24mb.   Who would not spend $1.68 in memory per picture to get lighting response.   If you store it at viewing size, it's probably just 6MB for 1600x1200 screens.  I have a 2560x1600 screen but I can handle it.