W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2012

Re: drop-shadow filter vs. a separate property

From: Chris Marrin <cmarrin@apple.com>
Date: Wed, 18 Jan 2012 15:23:16 -0800
Cc: public-fx@w3.org
Message-id: <11FF0D34-87E5-4FAD-8AEE-948D14773D83@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Jan 18, 2012, at 2:03 PM, Tab Atkins Jr. wrote:

> On Wed, Jan 18, 2012 at 1:53 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> I've been implementing hardware accelerated filters in WebKit and the drop-shadow filter is a real stumbling block. All of the hardware accelerated ways we have to implement it are problematic. It's a pretty complex filter, requiring two separate input paths, color channel swizzling, blur and blending of the inputs. All that is possible, but integrating it into a chain of other filters is difficult and has performance issues. For hardware, doing drop-shadow as a single operation after the filter chain is way easier. This is a small problem on desktop hardware, but a much bigger one on mobile hardware where resources are much more scarce.
>> 
>> So I got to thinking about why we have a drop-shadow filter at all. Drop shadow is a great feature for CSS and has been discussed a lot. But it seems like it could just as easily be done as a separate property that is applied after filtering. Then it would be like box-filter, but would use the alpha of the element rather than its bounds.
>> 
>> Most of the current CSS filters don't even affect the alpha channel, so there would be no way to tell where in the chain the drop-shadow appeared. So in most cases having a separate drop-shadow property would be functionally equivalent. I think the only time it would matter is with blur and another drop-shadow filter. In those two cases you'd get different results depending on whether or not you put the drop-shadow before of after the filter. I'm sure someone could come up with a use case where you could see the difference between a drop-shadow filter vs a property. But are such use cases essential?
>> 
>> I want to make sure these filters can be efficiently hardware accelerated. For Apple hardware at least (and I'm assuming other platforms have the same issues), doing drop shadow as a separate function after filters is easily hardware accelerated. But a drop shadow filter is very resource intensive.
>> 
>> Dean told me that this issue was discussed at a recent meeting that I didn't attend, but I haven't found any notes from that meeting. Can someone recap the rationale for wanting a drop-shadow filter rather than a property?
> 
> The immediate reason to want a drop-shadow filter is that drop shadows
> are very common, and it currently takes six filters to implement.
> Making a shortcut filter for it is just good sense.
> 
> I'm not sure if forcing it to always be after the rest of the filters
> would be acceptable or not - we'd have to look at existing usage of
> drop shadows.

But why are we thinking of this as a filter? Isn't it more like text-shadow or box-shadow than a filter? I mean, you can (and often do) implement them using a filter chain. But I don't see the motivation for having drop-shadow as a filter function rather  than a standalone property. In fact, now that I think of it, isn't having drop-shadow be a filter when text-shadow and box-shadow are not inconsistent?

I absolutely think we need a drop-shadow property. As Dean says, it gives you a way of adding a non-rectangular shadow to elements with alpha, which box-shadow does not. I just think we should consider making it a property rather than a filter function.

-----
~Chris
cmarrin@apple.com
Received on Wednesday, 18 January 2012 23:24:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 January 2012 23:24:32 GMT