Tilman Hausherr commented on PDFBOX-2092:

{quote}with a call to PDResources.getXObjects taking roughly half of that and 
PageDrawer.drawImage taking the other half.
That's the double decoding, which has been fixed in PDFBOX-3340.

Re the code by Petr: I believe something like this has been done in 
PDFBOX-3791, see "compromise between memory and time usage" code comment.

Re the patch by Petr: I haven't tested it due to the problems I mentioned, and 
because there is a new reason for not using it: we avoid the creation of custom 
formats, see PDFBOX-3854.

What remains in the profiler is related to the fact that this image is huge. 
Subsampling (PDFBOX-4137) can be one solution.

Another mystery is that rendering time for this file in PDFDebugger went up 
between 2.0.6 (2017-06-26) and 2.0.7 (2017-10-04). The cause is... PDFBOX-3854 

> Very slow rendering of scanned document
> ---------------------------------------
>                 Key: PDFBOX-2092
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-2092
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: Rendering
>    Affects Versions: 2.0.0
>         Environment: Win7 x64 EN
>            Reporter: Juraj Lonc
>            Priority: Major
>         Attachments: PDFBOX-2092.patch, SCAN_20140522_160457490_page2.pdf
> It takes extremely long to render this file to image.
> Depends on computer but it can take 15s+ to render 1 page.
> When I skip drawing of inserted image /Im0, then rendering is fast. So there 
> is something wrong with drawing that image in
> {code}
> PageDrawer.drawImage(Image awtImage, AffineTransform at)
> {code}
> when I comment out line 
> {code}
> graphics.drawImage(awtImage, imageTransform, null);
> {code}
> then rendering process takes 6s

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

Reply via email to