Bug 94053 - pdftoppm takes a long time to render a PDF
Summary: pdftoppm takes a long time to render a PDF
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: splash backend (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 90596
  Show dependency treegraph
 
Reported: 2016-02-08 22:47 UTC by Cory
Modified: 2016-02-16 00:45 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Remove limit check and use checkoverflow instead (1.12 KB, patch)
2016-02-11 14:26 UTC, Thomas Freitag
Details | Splinter Review
Remove limit check and use checkoverflow instead (1.20 KB, patch)
2016-02-12 09:30 UTC, Thomas Freitag
Details | Splinter Review
Adjust limit check and check in addition bitmap ponter (1.16 KB, patch)
2016-02-12 12:30 UTC, Thomas Freitag
Details | Splinter Review

Description Cory 2016-02-08 22:47:02 UTC
I have a PDF that takes around an hour to generate an image from. Ghostscript can render the same PDF in seconds. 

This is on Ubuntu 14.04 LTS with Poppler version 0.40.0

Unfortunately this is a PDF with sensitive user data. 
Please contact me and I can send you a link to the file. 

Thanks so much,
Cory
Comment 1 Thomas Freitag 2016-02-11 14:24:29 UTC
This PDF has a tilingPattern which doesn't use the tiling pattern implementation in splash introduced in 0.17.0 because it exceeds the limits for tilingPattern-Bitmaps introduced with solution of bug 52488.
Instead of slightly increase the limit I want now to use the checkoverflow implementation in SplashBitmap.
Comment 2 Thomas Freitag 2016-02-11 14:26:19 UTC
Created attachment 121674 [details] [review]
Remove limit check and use checkoverflow instead

This patch decreases the render time for this PDF from 80 minutes to 8 secondy on my laptop.
Comment 3 Thomas Freitag 2016-02-12 09:30:01 UTC
Created attachment 121704 [details] [review]
Remove limit check and use checkoverflow instead

Sorry, the fallback was buggy: of course we have to restore the original bitmap and delete the tilingPattern bitmap!
Comment 4 Thomas Freitag 2016-02-12 12:30:04 UTC
Created attachment 121707 [details] [review]
Adjust limit check and check in addition bitmap ponter

Sorry, after looking into bug 90596, which PDF wasn't yet part of my regression test, I got with this patch a "Bogus memory allocation size". Reason for it was there that in the later call of splash->drawImage the already huge bitmap was duplicated. It doesn't matter for the rendering quality, because after it it falls back to the Gfx implementation, but therefore the job was done twice, which is at least a waste of time.

Therefore I now adjust the limit check so that it works here AND with bug 90596.
Comment 5 Albert Astals Cid 2016-02-16 00:45:10 UTC
Pushed


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.