This looks like it is caused by poppler rerendering the pattern each time it
wants to draw it.

An other example that "eat CPU":
http://arxiv.org/pdf/cond-mat/0412004v3
the PDF-version. 

On Ubuntu 8.04
with evince 2.22.2 poppler 0.6.4

The problem can be in the 4th or 5th page. The first 3 page makes no problem.

(I found no example on the URL given in the description.)

In addition: with Acrobat Reader there is no problem.

Comment #2 PDF still freezes at page 6, using poppler 0.8.7 (cairo), evince 2.24.1

I've investigated things a little (and read the PDF spec to do so... a few hours ago, I had no idea how PDFs files were structured.). The page in question displays a bunch of plots with many many dots. sysprof says that most of the time is spent in cairo, stroking and filling some paths.

Part of the problem is that this PDF is just very poorly made.

pdf_inspector hangs while dumping a ton of data to the console:

m 3349.42 6798.69
c 3349.42 6802.36 3346.44 6805.34 3342.77 6805.34
c 3339.09 6805.34 3336.11 6802.36 3336.11 6798.69
c 3336.11 6795.02 3339.09 6792.04 3342.77 6792.04
c 3346.44 6792.04 3349.42 6795.02 3349.42 6798.69
f
m 3349.42 6798.69
c 3349.42 6802.36 3346.44 6805.34 3342.77 6805.34
c 3339.09 6805.34 3336.11 6802.36 3336.11 6798.69
c 3336.11 6795.02 3339.09 6792.04 3342.77 6792.04
c 3346.44 6792.04 3349.42 6795.02 3349.42 6798.69
S

(repeated a ton with different numbers)

That is, a moveTo, some curveTo, and then a stroke or a fill.  The two paths are identical, which is a first sign of the PDF being weird. :-) You would think that could be simply a fill on a larger path.


I also looked around the PDF file itself to see if the paths were referenced from somewhere and poppler was copying them without making cairo cache something. This is not the case. The stream with the contents of that page (the /Page is 141 0 R with /Contents 142 0 R) contains (under a /FlateDecode) about 12,000 lines worth of

2200.18 6576.24 m
2200.18 6579.91 2197.2 6582.89 2193.52 6582.89 c
2189.85 6582.89 2186.87 6579.91 2186.87 6576.24 c
2186.87 6572.57 2189.85 6569.59 2193.52 6569.59 c
2197.2 6569.59 2200.18 6572.57 2200.18 6576.24 c
S
2197.68 6609.51 m
2197.68 6613.18 2194.7 6616.16 2191.03 6616.16 c
2187.36 6616.16 2184.38 6613.18 2184.38 6609.51 c
2184.38 6605.84 2187.36 6602.86 2191.03 6602.86 c
2194.7 6602.86 2197.68 6605.84 2197.68 6609.51 c
f

So, the PDF really just contains that many drawing commands, and cairo is a wonderful little speed demon.


That said, it may still be poppler's fault. I tried loading it with Okular (on Ubuntu Jaunty's system poppler; the dev one crashed under LD_LIBRARY_PATH... ABI change?) and it also hangs.

Also, evinces gives me the following errors:
Error: Unable to allocate memory for image.
Error: Unable to allocate memory for image.
Error: Unable to allocate memory for image.
Error: Unable to allocate memory for image.

By adding extra debug outputs, they're HUGE allocations. On the order of 1-2GB, with the last two overflowing a signed int. Somehow, I suspect this is not the right thing to do. :-)

Will investigate further...

The PDF seems to render properly on poppler master. Still slow, but acroread also renders it slowly.

hello everyone, 

I think the issue with this pdf might be related (it appears the first page is extremly slow to load and uses a lot of cpu)

http://mrman.de/CASE.pdf

i've been using slackware 13 and kubuntu 9.10 with both okular and xpdf... same problem

best regards

chris

I cannot find the PDF from Sebastien anymore, but the PDF from comment 2 renders with the actual version in 25 sec, so less than 1 second / page, and also CASE.pdf renders in less than 1 second / page.
So this problem seems to be fixed now.

Marking fixed, if you still have a pdf file that has a huge cpu use please open a new bug and attach the pdf file there