Bug 205301 - add configurable aggressive prerendering
Summary: add configurable aggressive prerendering
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-27 09:11 UTC by Maciej Pilichowski
Modified: 2012-08-09 20:34 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2009-08-27 09:11:26 UTC
Version:            (using KDE 4.3.0)
Installed from:    SuSE RPMs

New/old report as Albert asked:
https://bugs.kde.org/show_bug.cgi?id=106230#c18

Such option would be a good idea for people with good CPU and free memory while reading documents. Current aggressive mode is not enough -- for example I can load 23-pages document, I still have 1.5GB free RAM and I cannot change page smoothly because kpdf renders it while I move.

I did a test -- 400 pages pdf file, current page 310, I get back to 300. From that point when I went to 301 the jump was immediate, but when I get back to 300 and then (after 5 minutes to be sure) to 299 I had to wait. So okular does not prerenders "surrounding" pages even in agressive mode.

My suggestion -- with such option switched on kpdf should use RAM to its maximum. Prerender pages backward and forward to given limit /*/ at the given zoom. If user move for example forward, prerender for one backward page, 2 /*/ forward. If user change zoom, start prerendering pages again but keeping the previous renderings /*; just for case if user set the previous zoom/.
So, after few seconds I could basically view static screens without images loading, text blur, etc.

/*/ -- just an example, I think all these should be configurable.
Comment 1 Maciej Pilichowski 2009-08-27 09:12:40 UTC
Wish of course, sorry for mis-click.
Comment 2 Pino Toscano 2009-08-27 12:12:55 UTC
Would be nice if you could actually verify whether preloading even in aggressive mode is not working, because okular has it slightly more aggressive than kpdf.

Also, would be nice to have ideas which don't involve new options at any cost. I know you like them, but adding lots of them is simply not the solution for any problem.
Comment 3 Maciej Pilichowski 2009-08-27 14:18:05 UTC
1) I checked, that is why I posted this report again

2) me too, but here is hard to do it, because you would have come up with some smart limit how many pages okular should prerender (IOW, I am out of better ideas). So it is not that I like the options, but when I don't see really smart behaviour on horizon, I simply rely on them to provide needed level of customization.

One I have maybe, but it is complex:
a) minimum, one back, one forward prerendered page
b) check if user waited for N-th page, if yes, extend the limit to N (up to available memory)

So for example, I am on page 10, I pressed 5 times pgup fast, okular notices it has to extend the limit from 1 to 5. When I am reading page 5, the cache is build for pages 1-4, 6 (this limit is not changed), plus they are remembered pages: 9, 10, 11 (from previous position).
Comment 4 Dan Leinir Turthra Jensen 2009-11-21 16:21:05 UTC
For what it's worth, this is particularly problematic for presentations: If you are doing a presentation, you currently have to jump into presentation mode, flick through all the slides, and then flip back to page 1 before you are ready to do your presentation, if you expect page flips to be instant while doing the actual presentation.

In other words: i can confirm this issue.

(using Okular 0.9.1 in KDE 4.3.1)
Comment 5 Albert Astals Cid 2012-08-09 20:34:42 UTC
Okular 0.15 has aggressive memory setting, this should help you.
Comment 6 Albert Astals Cid 2012-08-09 20:34:59 UTC
And by agrressive i mean greedy