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

drop-shadow filter vs. a separate property

From: Chris Marrin <cmarrin@apple.com>
Date: Wed, 18 Jan 2012 13:53:04 -0800
Message-id: <2FAA6337-9B69-40E2-97F4-340DFE04773F@apple.com>
To: public-fx@w3.org
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?

Received on Wednesday, 18 January 2012 21:53:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:46 UTC