Bug 218418 - Pre rendering and caching do not work on freebsd
Summary: Pre rendering and caching do not work on freebsd
Alias: None
Product: okular
Classification: Applications
Component: PDF backend (show other bugs)
Version: unspecified
Platform: FreeBSD Ports FreeBSD
: NOR normal
Target Milestone: ---
Assignee: Okular developers
Depends on:
Reported: 2009-12-12 19:50 UTC by Hannes H
Modified: 2010-12-18 02:08 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:

patch to calculate ram values on freebsd (5.47 KB, patch)
2010-12-08 23:37 UTC, Alberto Villa
second version of the patch, without style cleaning (5.11 KB, patch)
2010-12-09 10:18 UTC, Alberto Villa
third version of the patch, only freebsd code added (1.83 KB, patch)
2010-12-09 10:38 UTC, Alberto Villa
new patch including sys/types.h (1.86 KB, patch)
2010-12-13 11:29 UTC, Alberto Villa

Note You need to log in before you can comment on or make changes to this bug.
Description Hannes H 2009-12-12 19:50:17 UTC
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.


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!
Comment 1 Pino Toscano 2009-12-12 20:02:08 UTC
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).
Comment 2 Hannes H 2009-12-12 20:07:14 UTC
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.
Comment 3 Albert Astals Cid 2009-12-14 22:59:29 UTC
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.
Comment 4 Albert Astals Cid 2009-12-26 20:52:58 UTC
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?
Comment 5 Hannes H 2009-12-26 23:24:03 UTC
Maybe this does the job:


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…

Comment 6 Albert Astals Cid 2009-12-27 00:10:14 UTC
probably, but you are going to need someone to code a patch since none of us runs freebsd systems
Comment 7 Raphael Kubo da Costa 2009-12-28 03:53:18 UTC
Can you give some pointers on where the OS-specific stuff should go in Okular's source?
Comment 8 Pino Toscano 2009-12-28 10:43:03 UTC
(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. :)
Comment 9 Alexander Meshcheryakov 2010-05-08 17:37:50 UTC
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.
Comment 10 Albert Astals Cid 2010-05-10 15:42:06 UTC
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.
Comment 11 Albert Astals Cid 2010-05-10 16:58:49 UTC
Setting a better summary
Comment 12 Alberto Villa 2010-12-08 23:37:47 UTC
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
Comment 13 Albert Astals Cid 2010-12-09 00:15:57 UTC
Please, don't clean code, just send a patch that adds the freebsd support.
Comment 14 Alberto Villa 2010-12-09 10:18:50 UTC
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
Comment 15 Pino Toscano 2010-12-09 10:27:35 UTC
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.)
Comment 16 Alberto Villa 2010-12-09 10:38:46 UTC
Created attachment 54348 [details]
third version of the patch, only freebsd code added

ok, i understand
here's the patch
Comment 17 Alberto Villa 2010-12-13 11:29:11 UTC
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
Comment 18 Albert Astals Cid 2010-12-18 02:08:19 UTC
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