[ 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)