Bug 205301

Summary: add configurable aggressive prerendering
Product: [Applications] okular Reporter: Maciej Pilichowski <bluedzins>
Component: generalAssignee: Okular developers <okular-devel>
Status: RESOLVED FIXED    
Severity: wishlist CC: aacid, leinir
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Unspecified   
Latest Commit: Version Fixed In:

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