Bug 692287 - inefficient clipping
Summary: inefficient clipping
Status: RESOLVED FIXED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: fitz (show other bugs)
Version: unspecified
Hardware: PC Windows 7
: P4 normal
Assignee: Tor Andersson
URL: http://code.google.com/p/sumatrapdf/i...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-17 10:54 UTC by zeniko
Modified: 2011-07-09 11:57 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description zeniko 2011-06-17 10:54:32 UTC
http://home.infidel.name/heinlein.pdf renders very slowly due to hundreds of non-rectangular clipping areas forcing fitz/draw to render hundreds of pixmaps with masks (profiling showed that fz_paint_pixmap_with_mask is responsible for over 50% of the rendering time). Adobe Reader somehow manages this much more efficiently...
Comment 1 Robin Watts 2011-07-06 16:30:15 UTC
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.
Comment 2 Robin Watts 2011-07-09 11:57:31 UTC
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.