Bug 691317

Summary:	significant perf regression due to calling blendmaskover for every pdf_grestore
Product:	MuPDF	Reporter:	zeniko
Component:	mupdf	Assignee:	Tor Andersson <tor.andersson>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ralph.giles, robin.watts
Priority:	P4
Version:	unspecified
Hardware:	PC
OS:	Windows 7
URL:	http://code.google.com/p/sumatrapdf/issues/detail?id=930
Customer:		Word Size:	---

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. ***