[
https://issues.apache.org/jira/browse/PDFBOX-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15666355#comment-15666355
]
John Hewson edited comment on PDFBOX-3569 at 11/15/16 7:20 AM:
---------------------------------------------------------------
ColorConvertOp.filter is able to take advantage of hardware acceleration and
was chosen because it was by far the fastest approach. What's changed?
Note that if you're testing on VMs or AIX JVMs you're presumably not going to
get any hardware acceleration.
was (Author: jahewson):
ColorConvertOp.filter is able to take advantage of hardware acceleration and
was chosen because it was by far the fastest approach. What's changed?
> Performance regression in PDColorSpace#toRGBImageAWT
> ----------------------------------------------------
>
> Key: PDFBOX-3569
> URL: https://issues.apache.org/jira/browse/PDFBOX-3569
> Project: PDFBox
> Issue Type: Bug
> Components: Rendering
> Affects Versions: 2.0.3, 2.1.0
> Reporter: Andreas Lehmkühler
> Assignee: Andreas Lehmkühler
> Fix For: 2.0.4, 2.1.0
>
> Attachments: PDFBOX-1058.pdf-3.png, PDFBOX-1058.pdf-3.png,
> PDFBOX-1058.pdf-3.png-diff.png, PDFBOX-2700-JCS_YCCK.pdf-1.png,
> PDFBOX-2700-JCS_YCCK.pdf-1.png, PDFBOX-2700-JCS_YCCK.pdf-1.png-diff.png,
> PDFBOX-3569-patch_v2.txt
>
>
> I've a private pdf containing 1900 tiny inline images (CMYK, 8bit) which
> renders way too slow. Again the CMYK2RGB conversion is the culprit here, BUT
> the known issue with the KCMS/LCMS change isn't the main problem here.
> I ran some tests on linux (PDFToImage time -imageType png -resolution 150)
> 1.6.0_37: 355s
> 1.7.0_25: 289s
> 1.7.0_75: 298s
> 1.8.0_101: cancelled after 15 min
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
