After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 428784 - preload the next n images in editing mode and fullscreen
preload the next n images in editing mode and fullscreen
Status: RESOLVED WONTFIX
Product: f-spot
Classification: Other
Component: Browsing
SVN
Other All
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
gnome[unmaintained]
: 539854 556820 591232 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-04-11 21:37 UTC by Mike Gemünde
Modified: 2018-07-12 00:05 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mike Gemünde 2007-04-11 21:37:48 UTC
Switching Photos in fullscreen and editing mode is very slow. It seems to take a lot of time for loading the picture.
Why don't preload the next n (configurable in preferences) pictures (and scale down), so switching photos can be done much faster.

It would be nice to keep the previous photos in cache, so switching back would be faster, too.
Comment 1 Stanislaw Pitucha 2008-03-04 02:21:30 UTC
Just adding myself to CC and saying "others would like that too".
Feature seems to be popular on ubuntu brainstorm (http://brainstorm.ubuntu.com/idea/2738/) and still not supported in 0.4.2 - in fullscreen low-res version appears at once, but proper photo starts to render only after switching to next picture.
Comment 2 Olivier Cortes 2008-05-31 22:27:37 UTC
Just a me too. The “2 pass” loading of images is slow, and could be avoided with preloading next photo and keeping last photo in memory (for fast rewind). Preloading seems to be the default in Gthumb, and EOG seems to load images many times faster than F-Spot. I can't even find why it is so slow on my 2.2Ghz machine compared to other image viewers...
It is not a critic per se, I use F-spot heavily, it is my main image software. But for “quick filtering” photos at the end of a photo shooting, i must use another soft to delete out-of-focus or any other bad photos. That done, I can use F-spot on remaining photos.
Comment 3 Maxxer 2008-06-24 10:36:06 UTC
*** Bug 539854 has been marked as a duplicate of this bug. ***
Comment 4 antistress 2008-07-24 23:19:54 UTC
what about using something like Clutter to get hardware accelerated performances ?
Ubuntu Netbook Remix, Login Experience (aka GDM face browser), Eye of GNOME (maybe) are making use of it.
In the other hand, Eye of GNOME is already faster than F-Spot without OGL trick...
Comment 5 Maxxer 2008-10-19 06:42:28 UTC
*** Bug 556820 has been marked as a duplicate of this bug. ***
Comment 6 bart9h 2009-01-14 19:30:13 UTC
Speaking of cache, I'd like an option to keep a version of the photo at the screen resolution saved as a jpeg file, for ultra-fast browsing.

Also, the preloading should use threads (don't block the GUI, and make use of multi-core).
Comment 7 Maxxer 2009-08-10 07:05:51 UTC
*** Bug 591232 has been marked as a duplicate of this bug. ***
Comment 8 Милош Поповић 2010-09-08 22:23:29 UTC
Is someone considering this bug? It would still be a nice and easy to implement feature :)
Comment 9 André Klapper 2018-07-12 00:05:33 UTC
F-Spot has moved to https://github.com/f-spot/f-spot/issues

If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub.

Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.