Bug 82051 – Direct shadow casting by the background is an unnaturally *slow* path on some ports for some apps

• Status: NEW
• Component: Layout and Rendering

[Tom Hudson]

http://trac.webkit.org/changeset/107836 (https://bugs.webkit.org/show_bug.cgi?id=78728) caused a severe performance regression for Chromium: an app under development with a large scrolling div that casts a shadow went from 6ms/frame paint time to 40-50ms/frame paint time while scrolling, all of the additional time spent in a blur.

[Tom Hudson]

If I comment out two lines of the BoxShadow CL from Feb 15 (turning off the "fast path" in RenderBoxModelObject::fillPaintLayerExtended() and reactivating the "slow path" in RenderBox::paintBoxDecorations()), Chromium performance returns to what we were seeing before this change.

Sorry about that! I had no intention to make any port or any app slower. Are you able to attach a test case that shows this slowdown, or otherwise to tell whether r107836 made that case slower in the OS X, Quartz-based WebKit?

I think the way to address this probably would be to refine the logic that determines if the shadow should be cast by the background, but I am wondering if the decision should be dependent on the GraphicsContext implementation.

[Simon Fraser (smfr)]

Perhaps this should be considered to be a Skia performance bug?

(In reply to comment #3)
> Perhaps this should be considered to be a Skia performance bug?

We shouldn’t make changes in WebKit that make it slower, regardless of platform bugs.

[Tom Hudson]

It might be something in the platform glue for Chromium, rather than Skia? The new code path ends up being presented to Skia as a 4px radius gaussian blur of the 1000x800 div that's being scrolled; I presume CG is doing something much smarter if this is a fast path. I filed http://code.google.com/p/chromium/issues/detail?id=119778 against Chromium to see if I can get somebody familiar with those layers to take a look.