| Summary: | Pre rendering and caching do not work on freebsd | ||
|---|---|---|---|
| Product: | [Applications] okular | Reporter: | Hannes H <bugzilla> |
| Component: | PDF backend | Assignee: | Okular developers <okular-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander.s.m, avilla, markus, rakuco |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | FreeBSD Ports | ||
| OS: | FreeBSD | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
patch to calculate ram values on freebsd
second version of the patch, without style cleaning third version of the patch, only freebsd code added new patch including sys/types.h |
||
|
Description
Hannes H
2009-12-12 19:50:17 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). 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 |