Bug 691317 - significant perf regression due to calling blendmaskover for every pdf_grestore
Summary: significant perf regression due to calling blendmaskover for every pdf_grestore
Status: RESOLVED FIXED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: mupdf (show other bugs)
Version: unspecified
Hardware: PC Windows 7
: P4 normal
Assignee: Tor Andersson
URL: http://code.google.com/p/sumatrapdf/i...
Keywords:
: 690766 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-18 12:52 UTC by zeniko
Modified: 2010-05-20 22:21 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description zeniko 2010-05-18 12:52:03 UTC 
The document at the URL renders *very* slowly since the no-tree rewriting. Profiling shows that most of the time is spent in duff_4i1o1 (called from pdf_grestore -> fz_drawpopclip -> blendmaskover).
Comment 1 Robin Watts 2010-05-18 14:01:29 UTC 
I can confirm that Psychology_p354.pdf shows the same hotspot (70% of CPU on the beagleboard in this function).
Comment 2 Tor Andersson 2010-05-19 21:25:28 UTC 
Due to not having knowledge of the size of the contents being clipped, we were allocating scratch buffers the size of the clip mask rather than the size of the intersection between the clip mask and the contents. The sample PDF sets a new, almost page size rectangular clip mask for every individual path drawn.

I've implemented a special case for handling rectangular clip paths by scissoring the bounding boxes instead of rendering a the rectangular path to a clip mask.
Comment 3 Tor Andersson 2010-05-20 22:21:47 UTC 
*** Bug 690766 has been marked as a duplicate of this bug. ***