maemo.org Bugzilla – Bug 1052
The image viewer should cache the previous and the next image
Last modified: 2008-12-06 13:48:03 UTC
You need to
before you can comment on or make changes to this bug.
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.
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...
> Complain about the image loading speed instead
Yes, it would be nice if you could ALSO look into speeding up the JPEG decoding
> 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?
> 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:
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
I tend to close this as FIXED.