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