Version: (using Devel) Installed from: Compiled sources Hi, Here are 3 directions to explore to make the user experience smoother, especially at high zoom levels. 1) Find out why it's slower than XPDF. The speed in rendering difference becomes more obvious at high zoom levels (try 400%). XPDF uses Poppler-Splash, like Okular, so i'm really puzzled that it is faster! However, I really tried carefully, and I'm sure that it is at least here on my system... I built everything with default options; anyway both XPDF and Okular are using the same poppler. In Callgrind, it does seem that both Okular and XPDF spend most time in Poppler-Splash rendering. - XPDF spends most of its time in Page::displaySlice in xpdf itself. - Okular spends most of its time Page::displaySlice in libpoppler. Just a wild idea: could it be the fact that Okular displays "fuzzy" previews and it's actually consuming more CPU than expected? 2) At high zoom levels, when adjusting the zoom level, Okular first draws a white page, "erasing" the previously rendered page, before rendering the actual result. This seems useless, and distracting. This is very strange: I'm at 200% zoom level. I zoom up to 250%. Good: no white page rendered. I zoom up to 300%. Good: no white page rendered. I zoom up to 350%. BAD: WHITE PAGE RENDERED I zoom down to 300%. BAD: WHITE PAGE RENDERED I zoom down to 250%. BAD: WHITE PAGE RENDERED I zoom down to 200%. Good: no white page rendered. 3) A useful "cheat" to give the user a great speed impression, is that as soon as he has changed the zoom level, you display an instant preview by just scaling the existing image (the currently displayed page). This doesn't take any significant time and has a surprising effect on the user experience. The user is willing to forgive the not-quite-good quality of the preview because he knows it's temporary and he doesn't have time to look at it carefully anyway. That is also useful as it allows to know right away where the text will appear (useful at high zoom level). I implemented that in the Mandelbrot wallpaper plugin, as you can check. The code (very generic actually) is there: http://websvn.kde.org/trunk/KDE/kdeplasma-addons/wallpapers/mandelbrot/mandelbrot.cpp?view=markup See the zoomView() method. If you want, and if you can show me where and how I plug that into Okular, I volunteer to implement that.
Note: I did check that poppler (default build options) was built with -O2.
Also the sentence "both Okular and XPDF spend most time in Poppler-Splash rendering" is obviously wrong in view of the information that I gave just below, instead one should say that they both spend most time in displaySlice but * in Okular's case, it's the displaySlice provided by poppler-Splash * in XPDF's case, it has its own displaySlice I am attaching callgrind outputs...
Created attachment 37393 [details] Callgrind run on okular
Created attachment 37394 [details] Callgrind run on xpdf
One issue per bug report dude.
OK, I'm slicing it into 3 wishes/bugs. Feel free to close as... you decide.
OK, forget about the "performance" issue, I'm pretty sure it was subjective now. What happens is that Okular and XPDF have a different notion of " 100% Zoom ". So what was 100% Zoom in XPDF was actually more like 66% Zoom in Okular. Because of that, I've been comparing Okular at a higher zoom level, i.e. at a disadvantage. Also, at very high zoom levels, XPDF is sluggish when scrolling, which compensates for the greater speed of initial rendering.
I posted points 2) and 3) as issues #209630 and #209632.
What happens when rendering is the following: a new pixmap is asked for being rendered, and when ready replaces the old one [for a specified observer]. It -may- happen that, due to the memory usage, some other pixmap of the requested page (be it for the same observer or another) is removed, thus leaving no other pixmap for a page. This means that when rendering a page, any other available pixmap for the same page _is_ actually used. Regarding the white page at higher zoom, this can have two main causes: a) what I said above (ie previous pixmap being removed for memory constraint) b) a page pixmap too big (you see that by reading the debug output, only the first time); in that case, only a planned tiled rendering could fix this issue. (Also, why is such discussion being done on bugzilla, and not in ML?)
> (Also, why is such discussion being done on bugzilla, and not in ML?) Because when I wrote that, I didn't know that it would be as "interesting" as you suggest in #9, I thought that 2) was a plain simple bug in Okular and 3) was just a usual wishlist item. I didn't realize that Okular was so dependent on X's pixmap memory management. Naively one would think that X's memory management is only an internal thing that doesn't have to affect such visual aspects! So the naive question is this: why not just simply do all the rendering (of the current page / view) in, say, a QImage that X doesn't care about? Here I half expect my question to be stupid because I don't understand X client/server issues and what happens when people do e.g. X-over-a-network, but I'd honestly like to understand :)
Closing bug as said by reporter. Benoît if you want a quick explanation of why QPixmap and not QImage, ask on irc
Final comment on the "performance issue", what I was experiencing was what is now described here: https://bugs.kde.org/show_bug.cgi?id=209680