Summary: | Large PDF pages cause Okular to crawl | ||
---|---|---|---|
Product: | [Applications] okular | Reporter: | Diederik van der Boor <vdboor> |
Component: | PDF backend | Assignee: | Okular developers <okular-devel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aacid, bluedzins, eric.brunet, iorsh, jacob.benoit.1, kde, Martin.vGagern, oceanofsolaris |
Priority: | NOR | ||
Version: | 0.7.2 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Diederik van der Boor
2008-10-27 14:28:12 UTC
Document, please. Hi, can you please attach a sample document showing the issue? Also, please note which version of the poppler-qt4 library you have installed. For the record, I e-mailed the document to Pino Toscano since it's still copyrighted by the designer. (from which I asked approval to e-mail the document). (In reply to comment #3) > For the record, I e-mailed the document to Pino Toscano I did not receive it, sorry. ok, I've sent it again. (In reply to comment #5) > ok, I've sent it again. Received, thanks. This is a really big document. Okular has a "protection" to avoid rendering pages whose area at the current zoom level is more than 20.000.000 pixels, but of course for smaller areas it will take some memory. The problem is basically similar to the reason why the maximum zoom level is 400%. I can understand the reasons behind it, since it would generate a very large bitmap in the memory. Adobe's Acrobat reader can render the document quite fast btw. I guess they're using some kind of "tile engine" (like Google Maps) to avoid these issues. *** Bug 177011 has been marked as a duplicate of this bug. *** I have the same (?) problem on a public and useful document: the full map of Paris city bus with the streets: The map can be downloaded from http://www.ratp.info/orienter/f_plan.php?fm=gif&loc=reseaux&nompdf=bus_paris_geo&lang= (or, more user-friendly, click on ''Plan des bus avec rues'' from http://www.ratp.info/orienter/bus.php) I can view this with okular at 90%, but not at 100% on okular 0.9, in kde 4.3.0 *** Bug 185676 has been marked as a duplicate of this bug. *** Confirmed by duplicate For my PDF, the same. At small resolutions (below 100%), very slow display. Above 100% - no display at all. See https://docs.google.com/file/d/14hFFrjSSbiEcfML1sgOttcT865GC7tHqv27wiuEfQ-KlvuRfU67Dkj9E9JaM/edit For comparison, PDF-XChange Viewer for Windows is blazingly fast. Please report bugs of slowlyness rendering of PDF files at bugs.freedesktop.org against the poppler product since we use the poppler library for rendering PDF so there is not much we can do to increase the speed from the Okular side (In reply to comment #13) > there is not much we can do to increase the speed from the Okular side This bug here is due to the fact that Okilar renders THE WHOLE DOCUMENT into an off-screen image. Note that bug #185676 (and its duplicates), which was (imho correctly) resolved a duplicate of this one here, is not about slowness, but about an out of memory condition. So the fix to both issues would be only rendering a portion of the PDF file. This might be the portion currently visible, or might be some set of tiles to help scrolling. In either case, memory consumption sould go down, and there is a good chance that speed would go up as well. The Poppler::Page::renderToImage function DOES support rendering of only a portion of the image. So I'd suggest making use of that, and only if rendering remasins slow, THEN it is time to bug upstream about this. Until then, please REOPEN this bug. The file in comment#12 has an embedded 21590 x 161385 b/w bitmap. Ok, reopening then, my bad for not reading the bug correctly. Anyone can check if they are happy with the results produced by the current master git branch of okular (that if you know how to compile from git, etc, otherwise just wait for 4.10) Please see related bug in poppler bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56858#c6 There is a discussion about rendering tile-by-tile versus complete page rendering. Being the poppler maintainer, i'm aware of it. This looks partially fixed with okular 4.10. Looking at the pdf from comment#12 , I can at least look at the image at higher zoom levels (it's not 'blazingly' fast by any standards though, takes about at minute to render even a small part of the document). Kudos to the Okular developers for 4.10, okular got much better for me personally (finally more than 400% zoom!). I'm running 4.10.5 on F19 and still suffering from ridiculously slow page thumbnail generation and page rendering. This was also present on the Ubuntu 13.04 KDE spin. The poppler-qt lib is 0.22.1. For example, rendering some of the page thumbs for this pdf take roughly 20 seconds and the actual pages around 15 seconds: http://www.skrolli.fi/2013.2.web.pdf on a Core-i7. (To be fair, Evince suffers from similar lag in rendering the pages). With Adobe Reader, Foxit reader and Sumatra PDF rendering is pretty much instantaneous even with the cover pages. I'm expecting to get similar performance with Okular. Orso is your pdf a "large pdf"? Seems a regular A4. Does not qualify as large in my book of large things. Anyway i'm closing this bug as fixed if you have separate please open separate bugs, otherwise it's going to turn into the regular bug dump that it's impossible to fix because there's lots of users complaining about lots of different and unrelated things |