Bug 1052 - The image viewer should cache the previous and the next image
: The image viewer should cache the previous and the next image
Status: RESOLVED FIXED
Product: Images and Camera
Image viewer
: unspecified
: All Maemo
: Low enhancement with 7 votes (vote)
: 4.1
Assigned To: unassigned
: image-viewer-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2007-02-13 12:21 UTC by Kenneth Rohde Christiansen
Modified: 2008-12-06 13:48 UTC (History)
3 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Kenneth Rohde Christiansen (reporter) 2007-02-13 12:21:19 UTC
Often when I look at a picture I look at it some time (maybe 20-30 seconds)
which should be enough to cache the next image. 

It seems that the current situation is that it first loads the next image when I
go to it, ie. making the viewer seem slow and not smooth. 

This can be improved with a bit of caching.
Comment 1 Eero Tamminen nokia 2007-04-26 13:28:22 UTC
The images are large, for example 3 megapixel image takes 9 MB of RAM.
I think this is going to be wontfix.

Complain about the image loading speed instead and attach an image
that demonstrates this.  :-)

If you want to have the Apple iPhone approach, on Linux you can convert
the images to something more suitable sized with something like:
  for i in *.jpg; do mv  $i $i.bak; convert -geometry 800x480 $i.bak $i; done
before transferring them to the device...
Comment 2 Hanno Zulla 2007-04-26 14:26:08 UTC
> Complain about the image loading speed instead

Yes, it would be nice if you could ALSO look into speeding up the JPEG decoding
library ;-)

> The images are large, for example 3 megapixel image takes 9 MB of RAM.

I know little about JPEG decoding, but is it really necessairy to always decode
the full image? Shouldn't it be enough to just decode and scale those parts that
are visible on the screen?

http://primates.ximian.com/~federico/news-2005-11.html#moz-images

> I think this is going to be wontfix.

Uhm, you misunderstood me. You don't need to load the full next and previous
uncompressed images into memory.

Here's the proposal:

1) While the user is looking at image #9...

2) ...the image loader should load AND scale image #10 into memory, so that the
next 800x480 "screen" is already prepared and available in memory.

3) It would be even nicer if it would do the same for #8 right after loading and
scaling #10 and the user still looks at #9.

4) As a result, the user can then move forward and back instantly.

5) When browsing forward, the loader just shifts screens:

   previous = current
   current = next
   next = (do step 2 described above in the background)

   and vice versa for browsing backwards. That way, the image loader has to work
on one screen at a time, not on three for each step.

Check out quiver. It is a lot nicer in that regard:
http://test.maemo.org/downloads/product/quiver/
Comment 3 Andre Klapper maemo.org 2008-09-01 17:19:21 UTC
Preloading was implemented in Diablo. It does preloading only if there is
enough free memory, so it doesn't really preload anything in case of 10MP
images.

I tend to close this as FIXED.