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 320567 - evince needs lookahead and lookbehind caching
evince needs lookahead and lookbehind caching
Status: RESOLVED OBSOLETE
Product: evince
Classification: Core
Component: general
unspecified
Other Linux
: Low enhancement
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-11-03 02:58 UTC by Alan Siu-Lung Tam
Modified: 2018-05-22 13:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alan Siu-Lung Tam 2005-11-03 02:58:13 UTC
Distribution/Version: Ubuntu Breezy

Although the temporary white page (bug 320352) is the greatest inconvence, it is
another inconvent to load pages too slow. Imagine a page renders in > 0.5
seconds during a presentation. It is already annoying to move to the next page a
bit slow (imagine bug 320352 is fixed - press the button and nothing changed
until 0.5 seconds later it suddenly goes to the new page). Skipping 3 pages at a
time is pretty much unacceptablely slow.

I think evince should cache (at least) a couple of (say 5) pages before and
after the current page, so that they can be reached nearly instanteously.

It doesn't seem necessary to "forget" the cached pages, since during
presentation time, I probably only need evince to work - I won't care other
applications being swapped out of RAM due to evince requiring more RAM.
Comment 1 Alan Siu-Lung Tam 2006-05-01 06:48:23 UTC
Hello! Now that you tell everyone should use evince to replace ggv and gpdf, but you ignore major bugs that make it unusable, for 6 months.
Comment 2 Nickolay V. Shmyrev 2006-08-05 00:13:57 UTC
Well, it could be done, someone should just handle this problem and write a patch. But probably just faster rendering will help more.
Comment 3 Alan Siu-Lung Tam 2006-10-24 20:10:58 UTC
So another 6 months. For the past year, I can only either use gpdf (compile from source of course, which distro still comes with it?) or adobe reader (non-free!) for presentation. Perhaps I should try kpdf?

Faster rendering can solve a lot of problems. But it is not easy to do either. Caching is a easier and more sensible approach. During presentation, one stops in the slide for at least a few seconds. Why not take this time to render? In the Q&A session, perhaps you need to go back 20 pages to illustrate a point. At present, going back these 20 pages takes way too much time!

A typical presentation have at most around a hundred slides. Each slide takes the screen size, i.e. a few megabyte (uncompressed). A typical computer is capable of caching at least a fraction of the slides, if not all.

This is the reason there is a "presentation mode" - it should be optimized for presentation, during which the computer does nothing else. Of course this feature maybe useful for normal use, but caching should be less aggressive.
Comment 4 Philip Ganchev 2007-02-22 00:47:48 UTC
And in normal mode it should be conscious of the current free memory on the computer, to prevent thrashing.
Comment 5 Havoc Pennington 2008-08-29 15:16:59 UTC
Bug #342110 is somewhat related, to keep thumbnails in memory. Usability-wise, either thumbnails or the actual pages need to be possible to quickly flip through, that's the issue.
Comment 6 GNOME Infrastructure Team 2018-05-22 13:06:27 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/18.