- From: Chris Marrin <cmarrin@apple.com>
- Date: Tue, 24 Jan 2012 10:03:11 -0800
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: Brad Kemper <brad.kemper@gmail.com>, Dirk Schulze <dschulze@adobe.com>, Dean Jackson <dino@apple.com>, "TabAtkins Jr." <jackalmage@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>
On Jan 23, 2012, at 2:37 PM, Rik Cabanier wrote: > > > ... > I forgot that the properties are applied before filtering. This makes drop shadow as a property less interesting since you likely want to filter the source and then apply a drop shadow to it. > Applying effects on the shadow's color and shape are not as common... Why is it more interesting to apply a drop shadow after filters? Drop shadow uses opacity to produce the shadow effect, and the only CSS filters which affect opacity are blur (and drop-shadow itself). While there would be a difference in look if you applied a drop shadow before or after blur, I'm not sure drop shadowing post blur is somehow more useful than doing it before. And it seems like you'd want to apply a color effect (like sepia) to the shadow as well as the content. But I'm sure there are cases where you'd want to not have an effect like contrast affect the shadow. So I see the case for both. > > Why not optimize (or only implement) the case where a shadow is at the end of the filter chain and make it accelerated when the technology catches up? That sounds like a pretty arbitrary restriction. I suppose what we can say is that there will be platforms that will have performance issue if you start putting drop-shadow in arbitrary places in a filter chain. For now the WebKit implementation will certainly optimize the end-of-filter-chain case. We'll see how efficient we can make the rest. ----- ~Chris cmarrin@apple.com
Received on Tuesday, 24 January 2012 18:04:08 UTC