[gs-bugs] [Bug 692287] inefficient clipping

[bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=692287

Robin Watts <robin.watts at artifex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Robin Watts <robin.watts at artifex.com> 2011-07-09 11:57:31 UTC ---
Fixed.

commit 2c4bbbfdc7413a68cad395c3c61ff8e62dceb18b
Author: Robin Watts <Robin.Watts at 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.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.