Version: 4.3.4 (using KDE 4.3.4) OS: FreeBSD Installed from: FreeBSD Ports Performance is very poor, if working with PDFs that contain images. This has been the case for quite sometime, but it seems to be especially bad on high resolution-screens, possibly related to zooming. I have an AMD Phenom II 4X @ 3ghz and 4 GiB RAM, still with some PDF-Files it takes seconds for a new page to load clearly. My screen resolution is 2048x1152, Okular is set to aggrissive memory usage. I don't know if this is related to poppler, but I know it is faster with Adobe and with MuPDF. I have uploaded two screencasts demonstrating the slowness, the first is general usage / scrolling, the second is about zooming. The second also contains mupdf running on the same file. http://soulrebel.in-berlin.de/pub/okular_slow.ogv http://soulrebel.in-berlin.de/pub/okular_slow2.ogv Please note that I am not comparing with other software, because I think they are better (they are not), I am just trying to underline, that this behaviour is not "normal". I am not at liberty to make the PDF-File publicly available, but I can send it to a developer privately if that is needed. I think stuffing 100 JPGs in any PDF-File will do the trick though. Thanks for your help!
Do you perchance have a Linux installation on the very same machine of your FreeBSD one? If so, try also with it (possibly if the poppler and okular versions are the same).
I am sorry, I don't have a GNU/Linux install available right now. I also don't have an optical drive, so I can't check with a live-system (would be difficult because it being a live-system anyway). I do remember other GNU/Linux-users telling me about slow scrolling and zooming, when there are a lot of pictures in a file.
I'd appreciate the pdf file being public, so if you think stuffing 100 JPGs in any PDF-File will do the trick, please do it. If not, you can just drop the file at my inbox and i'll try to have a look.
Actually we just realized we don't have functions for reading total and free memory on FreeBSD so it always acts in a very conservative manner, do you know how to get these values in freebsd?
Maybe this does the job: http://www.freebsd.org/cgi/man.cgi?query=libmemstat&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE&format=html ? Should you have any patches that can be applied against a 4.3.4 tarball I can test them, building from SVN would be more trouble on FreeBSD… Thanks!
probably, but you are going to need someone to code a patch since none of us runs freebsd systems
Can you give some pointers on where the OS-specific stuff should go in Okular's source?
(In reply to comment #7) > Can you give some pointers on where the OS-specific stuff should go in Okular's > source? Sure: in okular/core/document.cpp, getTotalMemory() and getFreeMemory(). Feel free to ping me when ready for integration. :)
I have similar problem for quite a long time, and still have it with most recent release (Okular 0.10.3, KDE 4.4.3). Example document: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf In presentation mode on my main machine okular takes 2.5 seconds to render next page. In the meanwhile Evince is several times faster on the same document. Time required to show next page seems to be proportional of number of pixels which have to be rendered. To sift out probability of hardware, distro and configuration problems I tried same document on another machine booted from Kubuntu 10.04 Live CD and got same results: okular needs several times more time to show next page than Evince. Because these programs share poppler backend it seems to me this is Okular bug.
to commenter #9: No this bug has nothing to do with your problem, if you read the bug it is about a problem in freebsd. Also you seem to think that rendering a small image should take the same time than rendering a big image, are you serious? Also, that PDF renders in fullscreen instantaneously to me. And finally, you don't know how poppler works, so do not tell me that because both programs us poppler the bug is in okular.
Setting a better summary
Created attachment 54328 [details] patch to calculate ram values on freebsd the attached patch makes okular calculate the correct ram values on freebsd, and it cleans up the style of that part of the code. apparently it made okular a bit faster with some test documents in case the patch is accepted, i can commit it if you want
Please, don't clean code, just send a patch that adds the freebsd support.
Created attachment 54345 [details] second version of the patch, without style cleaning here it is the difference is minimal (it's just in the windows part), because all the other modifications are a consequence of a code rationalisation (which is not cleaning, it's avoiding duplication) i hope it's ok
The difference is far from minimal, yet. Please just add *only* the freebsd code, without touching the blocks of other OSes. (Also, I know you care more about freebsd than windows, but the -#ifdef Q_OS_WIN +#elif defined(Q_OS_WIN) change is not needed either.)
Created attachment 54348 [details] third version of the patch, only freebsd code added ok, i understand here's the patch
Created attachment 54493 [details] new patch including sys/types.h here's a new patch which includes sys/types.h, as we can't rely on it being included somewhere else
SVN commit 1207422 by aacid: Implement memory functions for freebsd Patch by Alberto Villa BUGS: 218418 M +30 -0 document.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1207422