Created attachment 35813 [details] file that is very slow to render The file at http://www.strassentheater-detmold.de/fileadmin/PDF_DATEN/Programm_nach_Tagen_FH_ENG_nach_%C3%84nderung.pdf takes a very long time to render. Maybe this is a cairo problem? This file also takes forever to render on my N900 which I think is based on xpdf directly, so might be an old issue? This is poppler version 0.8.7-3 (debian) I think. I have also attached the file just in case it disappears from the website.
Not evince specific
Created attachment 58950 [details] Rendering of this pdf is extremely slow
I'm sorry if I should have opened a separate bug for this; I don't know how to check whether it's related or not. The pdf I have here (see attachment) renders _extremely_ slowly (evince & okular; the file attached by the OP renders blazingly fast compared to this one). poppler version (openSUSE 12.1) is 0.18.0
Thanks for the new pdf. But next time, if you don't know if it's the same bug or not, please don't hijack other people bugs, it's much harder to properly mark it as fixed when there is random pdf attached to it that have nothing to do with eachother.
And yes, this pdf has nothing to do, so please open a separate bug.
Sorry again, I'll remember it for future reports. Separate bug report is here: https://bugs.freedesktop.org/show_bug.cgi?id=48051
In the actual version under ubuntu, 64 bit, it renders in 13 seconds, so 4-5 seconds per page. That seems to be a resonable time for me. And I can't see any problem with the PDF of comment 2 (s. bug 48051, too)
I get 3seconds per page in my laptop, but to be honest seems a bit too much for a "simple" page as that (text and some small images) i'd be interested in knowing why it's so slow
(In reply to comment #8) > I get 3seconds per page in my laptop, but to be honest seems a bit too much for > a "simple" page as that (text and some small images) i'd be interested in > knowing why it's so slow It's not just so "simple" You think: all the yellow symbols are images with a resolution of 4924.5 ppi, and because we don't cache xobjects, we read i.e. on page 1 70 images with such a resolution. This takes some time, even if the images are all jpeg compressed, so one of the compressions which can be really read quickly. Of course it would be quite easy to implement a caching for images. If we would do it, we would read i.e. the Euro sign on the first page only once instead of 8 times. But the next PDF producer probably even doesn't recognize that is is always the same sign and would insert 8 images instead of one, and then even a cache will not help anyway. Therefore I think that 3 seconds per page is acceptable for something like this.
Created attachment 61613 [details] Reduced image resolutions to 600 ppi with acrobat x I optimized the PDF with acrobat x. It has still a quite huge quality, i.e. can be zoomed highly before You begin to see pixels. But if You think that this is a common problem I would implement a cache some day...
Created attachment 88538 [details] Generated PDF using TikZ that renders REALLY slowly The other day I generated a PDF using LaTeX TikZ that renders really slowly in Evince (not in Okular or Mupdf...) So I guess it's a poppler-glib specific bug... In the attachment I include the PDF and the LaTeX sources
I have the same issue. File from first attachment renders very slow. Also, I found file with same problem. You can find it here http://dfiles.ru/files/2r1qpx7xm Sometimes render of page goes into infinite loop and never ends. I use qpdfview 0.4.7, poppler 0.24.5-1 on Debian.
Adrià, don't play with bug importance.
(In reply to comment #13) > Adrià, don't play with bug importance. Sorry, it was a test, I didn't know anyone could modify the bug importance :(
By the way I was wrong about the okular not bugging... It renders the file I attached much faster than evince, but once you zoom, there's a huge memory leak
You'll have to give proof it's a memory leak with a valgrind run output, otherwise i'm not keen of accepting people saying "it's a memory leak!"
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/209.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.