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.