[
https://issues.apache.org/jira/browse/PDFBOX-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026213#comment-14026213
]
Petr Slaby commented on PDFBOX-2126:
------------------------------------
... and I forgot to add - my test suite renders the first page of ~300 pdf
files (into AFP). The rendering before and after the change is identical.
Before the change, the test runs for about 340 seconds, after the change it
runs for about 220 seconds. Still way too much, but heading to the right
direction :-)
> Optimize clipping
> -----------------
>
> Key: PDFBOX-2126
> URL: https://issues.apache.org/jira/browse/PDFBOX-2126
> Project: PDFBox
> Issue Type: Improvement
> Components: Rendering
> Affects Versions: 2.0.0
> Reporter: Petr Slaby
> Attachments: ClipPath.patch, example_010.pdf
>
>
> As already stated in a TODO comment in PageDrawer, the call of
> Graphics2D#setClip() is time and memory consuming. The attached patch
> optimizes clipping by calling Graphics2D#setClip() only if the clipping path
> has changed. The effect depends on the document, e.g. the attached one
> renders in 10.5s without the optimization and in 5.5 seconds in the optimized
> version.
> The clipping has to be re-applied whenever the transform in Graphics2D
> changes. This is not explicitly checked for, the implementation rather
> depends on the cached value being reset manually. Currently this is only
> needed at one place when processing annotations (AcroForms). Also, the
> implementation relies upon the clipping path object stored in PDGraphicsState
> to never change so that a comparison using == can be used. This works fine,
> but needs a bit of awareness in future changes. To make the design more
> clean, the clipping path could be made private to PDGraphcisState and thus
> really "immutable" from outside.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
