Uploaded image for project: 'PDFBox'
  1. PDFBox
  2. PDFBOX-5258

Lazier clipping

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.0.24, 3.0.0 PDFBox
    • 2.0.25, 3.0.0 PDFBox
    • Rendering
    • None

    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.

      Attachments

        Activity

          People

            tilman Tilman Hausherr
            tilman Tilman Hausherr
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: