[Webkit-unassigned] [Bug 100413] [cg] RenderBlock::selectionGaps() is extremely slow when there are many floats

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Oct 25 14:45:48 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=100413





--- Comment #3 from mitz at webkit.org <mitz at webkit.org>  2012-10-25 14:46:56 PST ---
(In reply to comment #2)
> (From update of attachment 170730 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=170730&action=review
> 
> I’m OK with this, but I suspect there may be two other variations that work equally well or perhaps even better.
> 
> > Source/WebCore/ChangeLog:10
> > +        RenderBlock::selectionGaps() calls GraphicsContext::clipOut(const IntRect&) for each float.
> > +        With Core Graphics, A function that takes a vector of rectangles and clips them all out at
> > +        once is faster than multiple calls to the function that clips out a single rectangle.
> 
> Is the issue here the performance of repeatedly calling the CGContextGetClipBoundingBox function?

That’s the most expensive part. There’s also some function call overhead, but I didn’t profile this so I don’t know if it’s significant.

> 
> If so, could we fix this performance issue another way by simply using a wide open rectangle instead of calling CGContextGetClipBoundingBox?

I am going to try that.

> > Source/WebCore/platform/graphics/cg/GraphicsContextCG.cpp:1080
> > +        CGContextBeginPath(context);
> > +        CGContextAddRects(context, cgRects, 2);
> > +        CGContextEOClip(context);
> 
> Can the calls to CGContextBeginPath and CGContextEOClip be moved outside the loop? I don’t entirely understand the semantics here, but if all the rectangles are exclusive or'ed with each other, it seems that it could all be done with a single path.

We’d need to know that all rects in the input vector are pairwise disjoint.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list