[
https://issues.apache.org/jira/browse/PDFBOX-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048256#comment-14048256
]
Tilman Hausherr edited comment on PDFBOX-2126 at 6/30/14 10:29 PM:
-------------------------------------------------------------------
Some differences:
- The file from PDFBOX-1608 is rendered different, "veggie good" on the left is
grey instead of green
- The file from PDFBOX-1689 is rendered without the ELVIA title on the top left
- The file from PDFBOX-1689 is rendered on page 1 without EINLADUNG
There are many more, but maybe it is all the same reason (color?)
Nevertheless
{code}
the clipping path can't actually change in between BT and ET operators, so we
were calling setClip needlessly 15,000 times or so.
{code}
is a great observation.
was (Author: tilman):
Some difference:
- The file from PDFBOX-1608 is redered different, "veggie good" on the left is
grey instead of green
- The file from PDFBOX-1689 is rendered without the ELVIA title on the top left
- The file from PDFBOX-1689 is rendered on page 1 without EINLADUNG
There are many more, but maybe it is all the same reason (color?)
Nevertheless
{code}
the clipping path can't actually change in between BT and ET operators, so we
were calling setClip needlessly 15,000 times or so.
{code}
is a great observation.
> 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.1.patch, 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)