[PDFBOX-5258] Lazier clipping

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0.24, 3.0.0 PDFBox
• Fix Version/s: 2.0.25, 3.0.0 PDFBox
• Component/s: Rendering
• External issue URL: https://github.com/apache/pdfbox/pull/127
• Assignee: Tilman Hausherr
• Reporter: Tilman Hausherr
• Created: 14/Aug/21 12:22
• Updated: 17/Dec/21 06:50
• Resolved: 15/Aug/21 08:05

Description

From Stephan Schwiebert in linked PR:

Calculating the intersection of two Area can take a lot of time. However, depending on the Graphics2D that is used for rendering, it may not be necessary to actually perform this operation.

For instance, when generating an SVG, the individual clipping paths can be serialized individually, and the intersection is then calculated at runtime, when the SVG file is rendered.

The idea of this PR is to replace PDGraphicsState.clippingPath with a list of GeneralPaths, which is lazily evaluated, truncated & cached when getCurrentClippingPath() is called (effectively leaving the current behaviour of PdfBox unchanged, and it should also not have any significant impact on the performance).

Additionally, a new method protected void transferClip(PDGraphicsState graphicsState, Graphics2D graphics) is added to PageDrawer. By default, this method makes use of getCurrentClippingPath() to call graphics.setClip(...), which again is what PdfBox currently does.

However, classes that extend PageDrawer can override this method, and directly access the individual clipping paths, without any need to calculate their intersection.

In some cases (shading fills & transparency groups), it is still necessary to calculate the intersection.