-webkit-box-shadow and -webkit-border-radius are fine, on their own. When combined together, they kill redraw speeds. The page above informally demonstrates this - resizing the window is noticably slower when drop shadows & rounded corners are combined. If necessary, I could probably come up with some sort of animating benchmark thing...
Yeah, it is pretty slow even with relatively small number of boxes. Shark shows that time is mostly spent doing fills in GraphicsContext:: fillRoundedRect() (called from RenderObject::paintBoxShadow()).
There is a bug filed in Radar about this already. Upgrading to P1 to reflect the internal bug's status. We'll need to change the clipping to stroke a single path instead of using the multiple ellipse approach.
<rdar://problem/4994191> The internal bug isn't marked P1.
(In reply to comment #2) > We'll need to change the clipping to stroke a single path instead of using the > multiple ellipse approach. I'm trying to do this now.
Created attachment 14625 [details] [WIP] use a single rounded rect path Probably breaks non-Mac platforms. Fixes an existing box-shadow+border-radius bug when the radii cannot be satisfied (the box reverts to having straight corners, but the shadow goes all crazy). Didn't touch addInnerRoundedRectClip(), although it would be nice to get rid of it.
Created attachment 14626 [details] Use a single rounded rect path
Comment on attachment 14626 [details] Use a single rounded rect path In Path::createRoundedRectangle I would expect you to use float insted of double. FloatRect, etc. are actually "float" not double, and converting back and forth can be costly. Otherwise looks great. r=me
Comment on attachment 14626 [details] Use a single rounded rect path (In reply to comment #7) > (From update of attachment 14626 [details] [edit]) > In Path::createRoundedRectangle I would expect you to use float insted of > double. Copy&paste accident. I'm going to correct it.
Created attachment 14628 [details] Use single rounded rect path s/double/float/
Landed in r21601.