Bug 13518

Summary: Patterns are extremely slow to render
Product: poppler Reporter: Sven Arvidsson <sa>
Component: splash backendAssignee: poppler-bugs <poppler-bugs>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: carlosgc, csherrmann, freedesktop, gokcen.eraslan, guillaume.desmottes, kalpesh_4stars, krh, libreoffice.org, mattl, mickael.chazaux, nalimilan, ozancag, pramod.subramanyan, roozbeh, seb128, thomas9999, tiagomatos
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: slow document
Implement tiling patterns in cairo backend
Okular backtrace after crash
pdftops crash dump

Description Sven Arvidsson 2007-12-04 12:47:29 UTC
[ 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.
Comment 1 Sven Arvidsson 2007-12-04 12:47:59 UTC
Created attachment 12938 [details]
slow document
Comment 2 Albert Astals Cid 2007-12-05 10:11:57 UTC
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.
Comment 3 Albert Astals Cid 2007-12-05 10:19:46 UTC
And now spell it right :D
Comment 4 Albert Astals Cid 2007-12-13 14:34:58 UTC
*** Bug 13639 has been marked as a duplicate of this bug. ***
Comment 5 Albert Astals Cid 2007-12-13 14:36:20 UTC
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
Comment 6 Brad Hards 2007-12-25 22:52:07 UTC
*** Bug 3086 has been marked as a duplicate of this bug. ***
Comment 7 Albert Astals Cid 2008-05-25 13:25:40 UTC
*** Bug 16094 has been marked as a duplicate of this bug. ***
Comment 8 Albert Astals Cid 2009-01-15 11:24:31 UTC
*** Bug 19575 has been marked as a duplicate of this bug. ***
Comment 9 Albert Astals Cid 2009-01-27 11:34:27 UTC
*** Bug 19758 has been marked as a duplicate of this bug. ***
Comment 10 Albert Astals Cid 2009-03-26 14:32:08 UTC
*** Bug 20891 has been marked as a duplicate of this bug. ***
Comment 11 Albert Astals Cid 2009-05-10 13:21:40 UTC
*** Bug 21660 has been marked as a duplicate of this bug. ***
Comment 12 Albert Astals Cid 2009-06-17 13:05:56 UTC
*** Bug 6680 has been marked as a duplicate of this bug. ***
Comment 13 Albert Astals Cid 2009-07-28 10:58:01 UTC
*** Bug 22997 has been marked as a duplicate of this bug. ***
Comment 14 Carlos Garcia Campos 2009-08-13 06:11:01 UTC
Created attachment 28591 [details] [review]
Implement tiling patterns in cairo backend

These patches fix the bug for the cairo backend.
Comment 15 Albert Astals Cid 2009-08-15 09:08:48 UTC
I'd say the change to Gfx.cc is ok, though i don't see the need for m1x and m1y
Comment 16 Carlos Garcia Campos 2009-08-16 08:03:01 UTC
(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. 
Comment 17 Albert Astals Cid 2009-08-16 08:16:14 UTC
But the first thing done in the "fallback" code is assigning m1[4] and m1[5], so it doesn't matter, right?
Comment 18 Carlos Garcia Campos 2009-08-16 08:39:36 UTC
You are right, I've removed them and pushed the commits. 
Comment 19 Carlos Garcia Campos 2009-08-16 08:40:41 UTC
Moving to splash component since it's fixed in cairo backend now. 
Comment 20 Albert Astals Cid 2009-09-02 10:47:45 UTC
*** Bug 23652 has been marked as a duplicate of this bug. ***
Comment 21 Albert Astals Cid 2009-10-12 02:32:27 UTC
*** Bug 24389 has been marked as a duplicate of this bug. ***
Comment 22 Albert Astals Cid 2009-12-11 15:11:41 UTC
*** Bug 25591 has been marked as a duplicate of this bug. ***
Comment 23 Albert Astals Cid 2010-01-27 15:01:40 UTC
*** Bug 3233 has been marked as a duplicate of this bug. ***
Comment 24 Tristan Miller 2010-03-15 03:49:03 UTC
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?
Comment 25 Albert Astals Cid 2010-03-15 12:27:53 UTC
See comment #5

Or you want a user level tool?
Comment 26 Albert Astals Cid 2010-07-08 13:58:45 UTC
*** Bug 28954 has been marked as a duplicate of this bug. ***
Comment 27 Albert Astals Cid 2010-11-17 15:50:05 UTC
*** Bug 31671 has been marked as a duplicate of this bug. ***
Comment 28 Albert Astals Cid 2011-03-21 14:32:30 UTC
Will be fixed in poppler 0.18.
Comment 29 Ozan Çağlayan 2011-06-09 05:24:11 UTC
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.
Comment 30 Albert Astals Cid 2011-06-09 10:52:07 UTC
Can you reproduce the crash using pdftops?
Comment 31 Ozan Çağlayan 2011-06-13 00:48:09 UTC
Created attachment 47881 [details]
pdftops crash dump

Yes I can reproduce it, the backtrace is attached.
Comment 32 Ozan Çağlayan 2011-06-13 00:48:28 UTC
// Add me to CC
Comment 33 Albert Astals Cid 2011-06-13 10:58:09 UTC
The pdftops crash should be fixed on master, can you check¿
Comment 34 Ozan Çağlayan 2011-06-14 22:38:06 UTC
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.