← Back to team overview

registry team mailing list archive

[Bug 12613] Re: Xpdf renders really slow, non-responsive

 

Launchpad has imported 8 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=2709.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2005-03-12T05:17:57+00:00 Sebastien Bacher wrote:

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.

Reply at: https://bugs.launchpad.net/poppler/+bug/12613/comments/2

------------------------------------------------------------------------
On 2005-03-30T14:13:29+00:00 Jeff Muizelaar wrote:

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

Reply at: https://bugs.launchpad.net/poppler/+bug/12613/comments/8

------------------------------------------------------------------------
On 2009-01-07T15:15:36+00:00 Horváth Árpád wrote:

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

Reply at: https://bugs.launchpad.net/poppler/+bug/12613/comments/12

------------------------------------------------------------------------
On 2009-01-07T15:16:53+00:00 Horváth Árpád wrote:

In addition: with Acrobat Reader there is no problem.

Reply at: https://bugs.launchpad.net/poppler/+bug/12613/comments/13

------------------------------------------------------------------------
On 2009-05-15T13:19:41+00:00 Miguel Diago wrote:

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

Reply at: https://bugs.launchpad.net/poppler/+bug/12613/comments/14

------------------------------------------------------------------------
On 2009-06-20T21:34:47+00:00 David Benjamin wrote:

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

Reply at: https://bugs.launchpad.net/poppler/+bug/12613/comments/15

------------------------------------------------------------------------
On 2009-08-30T13:01:11+00:00 David Benjamin wrote:

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

Reply at: https://bugs.launchpad.net/poppler/+bug/12613/comments/16

------------------------------------------------------------------------
On 2009-12-11T09:33:50+00:00 Chris wrote:

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

Reply at: https://bugs.launchpad.net/poppler/+bug/12613/comments/17


** Changed in: poppler
   Importance: Unknown => Medium

** Bug watch added: GNOME Bug Tracker #169887
   https://bugzilla.gnome.org/show_bug.cgi?id=169887

-- 
Xpdf renders really slow, non-responsive
https://bugs.launchpad.net/bugs/12613
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Debian.