[
https://issues.apache.org/jira/browse/PDFBOX-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030107#comment-14030107
]
John Hewson commented on PDFBOX-2117:
-------------------------------------
That's much slower than I'd expect, but you seem to have found the reason:
{quote}
The method AxialShadingContext#getRaster() is called from AWT code when filling
an area. It is called many times, usually to produce a one pixel high raster.
{quote}
Huh. The smart thing for AWT Paint to do would be to render the entire area as
a rectangle and then clip it - I'm amazed that it's requesting 1x1 pixel
rasters - but not exactly surprised, based on past experience.
{quote}
PDDeviceRGB does nothing in getRGBImage() while it does a calculation through
sRGB in getRGB(). If I skip the call of getRGB() in the case of PDDeviceRGB
shading, the total time on this three files drops to 0.6s. For the moment, this
seems to be the best solution to me.
{quote}
I think we had some issues in the past with linear RGB vs sRGB, but I can't
find the JIRA issue... it might not matter for shading.
> AxialShadingContext is slow
> ---------------------------
>
> Key: PDFBOX-2117
> URL: https://issues.apache.org/jira/browse/PDFBOX-2117
> Project: PDFBox
> Issue Type: Improvement
> Reporter: Petr Slaby
> Attachments: 000001_MTEXT_CS6.pdf, AxialShading.patch,
> AxialShading1.patch, AxialShadingContext.java.getrgbimage,
> Shading2Function2text.pdf, asy-shade.pdf, color_gradient.pdf,
> shading_pattern.pdf
>
>
> AxialShadingContext#getRaster() is on top of profiler hot spots in documents
> that use an axial shading. Inside it, the slowest part is calling
> PDColorSpaceRGB#toRGB() and PDFunctionType3#eval() (in this order).
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
