Bug 692287

We have made some changes with clipping handling in light of this bug.

Without the changes @100dpi, this file takes 64seconds to render. With them, less than 5.

These will be committed after testing is complete.

Fixed.

commit 2c4bbbfdc7413a68cad395c3c61ff8e62dceb18b
Author: Robin Watts <Robin.Watts@artifex.com>
Date:   Wed Jul 6 16:32:33 2011 +0100

    Clip area optimisations for displaylist case:

    First, we add clipping rects to clipping functions. Various functions
    (the ones that handle clipping) are now additionally passed a rectangle
    that represents an additional bound for this clip in device space
    (i.e. it has already been mapped through the current ctm).

    Next, when constructing the displaylist, keep track of the bounding box
    for the contents of each clip.

    While writing the list, on every node we add, we add the bbox for that
    node to the enclosing clips content bbox (if there is an enclosing clip).
    When we pop a clip, write back to the corresponding push to update
    the bbox.

    This means if we get large clip regions, with only small areas used within
    them, we will only do the slow blending for those small areas.

    Finally, we fix a calculation in fz_bound_path which was incorrectly
    accounting for mitrelimits. This was showing up in testing on page 630
    of the PDF reference v1.7.