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

Re: [filter-effects] drop-shadow inset shadow

From: Brad Kemper <brad.kemper@gmail.com>
Date: Sun, 31 Mar 2013 07:53:40 -0700
Message-Id: <89FB0650-2896-4869-BE81-CDB6E37C220F@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>, Dean Jackson <dino@apple.com>, Alexandru Chiculita <achicu@adobe.com>
To: Michael Mullany <michael@sencha.com>
On Mar 30, 2013, at 4:18 PM, Michael Mullany <michael@sencha.com> wrote:

> 
> 
> On Sat, Mar 30, 2013 at 8:28 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Mar 30, 2013, at 8:05 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> 
>>> On Sat, Mar 30, 2013 at 7:28 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>>> Hi,
>>>> 
>>>> Currently the drop-shadow shorthand filter does not support inset shadows and the inset keyword (in comparison to box-shadow for instance). I wonder if this could be added to the spec and would like to hear implementers input.
>>>> 
>>>> Most shorthands have the advantage that they can easily be HW accelerated. This already seems not always be the case for drop-shadow on some platforms. However,  I do not think that it is harder to implement inset shadow, even if it will be of course slower than other filters.
>>>> 
>>>> Here is a short example how to use inset shadows with SVG Filters today[1]:
>>>> 
>>>>                <filter id="innershadow" x0="-50%" y0="-50%" width="200%" height="200%">
>>>>                        <feGaussianBlur in="SourceAlpha" stdDeviation="2" result="blur"/>
>>>>                        <feOffset dy="3" dx="3"/>
>>>>                        <feComposite in2="SourceAlpha" operator="arithmetic"
>>>>                                        k2="-1" k3="1" result="shadowDiff"/>
>>>>                        <feFlood flood-color="black" flood-opacity="1"/>
>>>>                        <feComposite in2="shadowDiff" operator="in"/>
>>>>                        <feComposite in2="SourceGraphic" operator="over"/>
>>>>                </filter>
>>>> 
>>>> Implementations could replace the inset shadow in the CSS string with an equivalent filter chain as above.
>>>> 
>>>> Greetings,
>>>> Dirk
>>>> [1] http://ledrug.wordpress.com/2010/09/30/learning-svg-lesson-2/
>>> 
>>> +1, and it would also be nice to support spread, if that's possible to
>>> do in filters.
>> 
>> I agree. I haven't tried Dirk's code, but I do hope filters can gain the ability to do inner shadows and spread. I don't know what primitives can be used to create the spread effect, though. It seems like it needs something like PhotoShop's 'maximize' and 'minimize' filters:
>> 
>> http://help.adobe.com/en_US/photoshop/cs/using/WSfd1234e1c4b69f30ea53e41001031ab64-7970a.html#WSfd1234e1c4b69f30ea53e41001031ab64-795da
> 
> I think spread could be implemented by adding a circular input option to feMorphology (currently it uses a square as its input area and produces blocky results).

You're right. I didn't notice feMorphology, but based on its stated intent in the description (fattening or thinning the artwork), it seems like the right sort of thing. I guess the square is so that you could maintain sharp corners on unrotated rectangles, but it wouldn't really help with other corner shapes.

When I tried the SVG sample on my iPad, and zoomed in, the words that had the filter applied looked blurry, and it seemed like it might be worse for the higher radiuses. Thats not good. Is this an inherent problem with this method? Or with using a square? Or is it just a WebKit thing? Perhaps it is having the effect of exaggerating the anti-aliasing?
Received on Sunday, 31 March 2013 14:54:16 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:54:18 UTC