[ From http://bugs.debian.org/443547 ] The attached PDF is extremely slow to render in Evince, using Poppler 0.6.2 (cairo backend), it seems to be equally slow in Xpdf. "cairo context error: NULL pointer" is printed on the terminal.
Created attachment 12938 [details] slow document
This is because the document has a Pattern which makes it slow down a lot, i though we had already a "Patterns are slow" bug, but as i can't find it i'll reuse this one. See http://bugs.kde.org/show_bug.cgi?id=99486 for more info.
And now spell it right :D
*** Bug 13639 has been marked as a duplicate of this bug. ***
To check if a document that takes very long to render or not is hit by this bug just put a return on the beginning of Gfx::doPatternFill and Gfx::doPatternStroke if it automatically goes fast again, you've hit a duplicate of the magnificient and sucking "Patterns are extremely slow to render" bug
*** Bug 3086 has been marked as a duplicate of this bug. ***
*** Bug 16094 has been marked as a duplicate of this bug. ***
*** Bug 19575 has been marked as a duplicate of this bug. ***
*** Bug 19758 has been marked as a duplicate of this bug. ***
*** Bug 20891 has been marked as a duplicate of this bug. ***
*** Bug 21660 has been marked as a duplicate of this bug. ***
*** Bug 6680 has been marked as a duplicate of this bug. ***
*** Bug 22997 has been marked as a duplicate of this bug. ***
Created attachment 28591 [details] [review] Implement tiling patterns in cairo backend These patches fix the bug for the cairo backend.
I'd say the change to Gfx.cc is ok, though i don't see the need for m1x and m1y
(In reply to comment #15) > I'd say the change to Gfx.cc is ok, though i don't see the need for m1x and m1y > m1x and m1y are needed to restore m1[4] and m1[5] in case of falling back to Gfx code when out->tilingPatternFill() returns false.
But the first thing done in the "fallback" code is assigning m1[4] and m1[5], so it doesn't matter, right?
You are right, I've removed them and pushed the commits.
Moving to splash component since it's fixed in cairo backend now.
*** Bug 23652 has been marked as a duplicate of this bug. ***
*** Bug 24389 has been marked as a duplicate of this bug. ***
*** Bug 25591 has been marked as a duplicate of this bug. ***
*** Bug 3233 has been marked as a duplicate of this bug. ***
I have a document which is also slow to render (using Okular). What's the best way of determining whether it's because of this pattern bug, or because of something else? Is there some command-line tool which will tell me whether a given PDF has a pattern?
See comment #5 Or you want a user level tool?
*** Bug 28954 has been marked as a duplicate of this bug. ***
*** Bug 31671 has been marked as a duplicate of this bug. ***
Will be fixed in poppler 0.18.
Created attachment 47764 [details] Okular backtrace after crash Hi, With this fix applied, the PDF documents which were affected by this pattern bug, crashes Okular when Print or Print Preview is clicked. Reverting the commit fixes the crash but restores the slow rendering behaviour. Attached is the crashdump. I can reproduce the with the PDF attached to this bug called overall.pdf. (This is on KDE 4.6.3 BTW) Thanks.
Can you reproduce the crash using pdftops?
Created attachment 47881 [details] pdftops crash dump Yes I can reproduce it, the backtrace is attached.
// Add me to CC
The pdftops crash should be fixed on master, can you check¿
Yes it both fixed pdftops and okular crashes but the print preview screen is very slow while generating previews. Thanks.
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.