Xpdf renders really slow, non-responsive

[Theo van Klaveren]

Xpdf renders the attached file really slow, taking about 1 minute per page,
being non-responsive in the meantime. Switching pages incurs the 1 minute delay
every time. Acrobat reader has no problems, rendering it in about 1 second on my
Athlon XP 2500+. Any other program that uses Xpdf's engine for rendering
(Gnome-pdf-viewer, Evince) also exhibits this bug. I have no problem with other
documents.

https://bugs.freedesktop.org/show_bug.cgi?id=2709: https://bugs.freedesktop.org/show_bug.cgi?id=2709

[Theo van Klaveren (t-vanklaveren)]

Created an attachment (id=1286)
Problematic PDF

[Sebastien Bacher (seb128)]

I've opened a bug against evince but that seems to be a poppler issue according
to http://bugzilla.gnome.org/show_bug.cgi?id=169887.

you can find an example here:
https://bugzilla.ubuntu.com/attachment.cgi?id=1286

Acroread opens this file fine.

[Sebastien Bacher (seb128)]

right, I've opened a bug upstream on poppler (the freedesktop fork of xpdf) for it:
https://bugs.freedesktop.org/show_bug.cgi?id=2709

[Hamish Moffatt (hamish)]

Why did you report this to an upstream fork, rather than to Derek Noonburn
<email address hidden>, the original author?

Alternatively report it to Debian. I can group it with existing reports of this
nature and forward the details upstream.

Hamish

[Sebastien Bacher (seb128)]

(In reply to comment #3)
> Why did you report this to an upstream fork, rather than to Derek Noonburn
> <email address hidden>, the original author?

Because I don't know the bug tracker for xpdf and because we have planned to
switch the default pdf viewer to evince that uses poppler.

> Alternatively report it to Debian. I can group it with existing reports of this
> nature and forward the details upstream.

Seems to be the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231208,
any interest to open a new bug ?

[Hamish Moffatt (hamish)]

(In reply to comment #4)
> (In reply to comment #3)
> > Why did you report this to an upstream fork, rather than to Derek Noonburn
> > <email address hidden>, the original author?
>
> Because I don't know the bug tracker for xpdf and because we have planned to
> switch the default pdf viewer to evince that uses poppler.

There is no public bug tracker for Xpdf. Email <email address hidden> directly.

Even if you switch your default pdf viewer, you presumably wouldn't call the
package "xpdf".

> > Alternatively report it to Debian. I can group it with existing reports of this
> > nature and forward the details upstream.
>
> Seems to be the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231208,
> any interest to open a new bug ?

No need, existing bug looks OK. I'll add some extra information to Debian BTS.

Hamish

[Sebastien Bacher (seb128)]

(In reply to comment #5)

> Even if you switch your default pdf viewer, you presumably wouldn't call the
> package "xpdf".

no, but we don't have a poppler component in bugzilla for the moment that's why
this bug is on xpdf.

> No need, existing bug looks OK. I'll add some extra information to Debian BTS.

thanks

[Jeff Muizelaar (jeff-infidigm)]

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

[Dietmar Hofer (didi156)]

Created an attachment (id=2168)
another problematic pdf

With this pdf I have the same problem described here. Starting from page 39 it
takes VERY long to render (but doesn't crash). It's PDF version 1.4 btw, maybe
that matters.

[Berti (bertrand-haut-gmail)]

Created an attachment (id=4552)
A third problematic pdf file

xpdf (all versions & all distributions I've tested) takes a really long time to
be able to display this single page document.

acroread has no problem.
kpdf is much more faster BUT a part of the image is missing (the barcode) BUT
this part was present in the printing.

[Daniel Robitaille (robitaille)]

Confirmed using both evince and xpdf in Dapper; it takes a minute or so to render which page.

Using kghostview, it rendered in a few seconds

[Horváth Árpád (horvath-arpad-roik)]

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.)

[Horváth Árpád (horvath-arpad-roik)]

In addition: with Acrobat Reader there is no problem.

[Miguel Diago (mdm)]

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

[David Benjamin (davidben)]

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...

[David Benjamin (davidben)]

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

[Chris (csherrmann)]

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

[Mark Summerfield (mark-qtrac)]

I have a program that uses the libpoppler-qt4-dev package. In Ubuntu 9.10 the poppler version for that package is 0.12.0 and my program runs very fast. But now that I've upgraded to Ubuntu 10.04 the poppler version for the package is 0.12.4 and my program's speed has *dramatically declined*. I supect that this problem may be the same as the one discussed here.

I did a local build of poppler 0.14.0 and rebuilt my program and linked against 0.14.0 and the program ran at its proper speed. So there really does seem to be a problem with poppler 0.12.4.

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for posting this bug.

Does this occur in Lucid?

[Tyler Gates (tgates81)]

I can confirm it still happens in Lucid.

[rusivi2 (rusivi2-deactivatedaccount)]

In Maverick (granted I was VirtualBox'ing with Toshiba Satellite L305D-S5934) I checked 'third Problematic pdf file' and it took about 3 minutes with XPDF while less than 2 seconds with Evince. Confirming.

[Tyler Gates (tgates81)]

After upgrading to Maverick xpdf packages on 10.04 Lucid (xpdf_3.02-9ubuntu1_all xpdf-reader_3.02-9ubuntu1_i386 xpdf-common_3.02-9ubuntu1_all) The issue is resolved.

[thomasfr (thomas-freitag)]

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.

[Albert Astals Cid (aacid)]

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

[Florian Schlichting (fschlich)]

this was fixed in Poppler in 2012, and hence can be marked as fixed here