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

On Mon, Apr 1, 2013 at 6:30 PM, Michael Mullany <michael@sencha.com> wrote:

> On Mon, Apr 1, 2013 at 2:23 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>
>>
>> On Apr 1, 2013, at 1:53 PM, Dean Jackson <dino@apple.com> wrote:
>>
>> > I'm torn here because my position is that shorthands are supposed to
>> serve two purposes:
>> >
>> > 1. Extremely easy to author. You proposal definitely wins here because
>> it reduces the difference from CSS box shadows.
>>
>> Yes, the compatibility to the syntax of box-shadow is one reason. But
>> there are indeed requests for inset shadows.
>>
>> >
>> > 2. Optimised for performance. Here's where "inset" gets tricky. As you
>> mention below, we've now got three compositions, or a clip depending on how
>> you do it. That one word could have a significant penalty on performance.
>>
>> I agree, inset shadows definitely need some extra calculation cycles,
>> even if I agree with Rik that the example code is not the ideal way and can
>> be optimized to use more basic functionality (no arithmetic compositing).
>>
>> However, even if it is slower, I am sure web authors would appreciate
>> more compatibility to box-shadow. After all, web authors use box-shadow
>> where they actually want to use drop-shaow.
>>
>> >
>> > A while back I proposed some extensions to shorthand filters to allow
>> blending with the original input. While people supported the proposal, I
>> backed off because I wanted to get the simplest possible thing in the spec
>> and out in the wild, then see what happened. My (unscientific) guess at the
>> moment is that the builtin filters are not fast enough on all platforms,
>>
>
> I've tested SVG filters on some mobile platforms. From my testing, basic
> filters (5ish primitives, no high order convolutions) are decently fast for
> the most part. Android is the poor performer (as usual). Animations are
> even possible. Here are my eyeball and unscientific estimates (it might be
> good to develop some benchmark filters.)
>
> Mobile:
> - iPad 2 is slow (0.4s lags) but iPad 4 is pretty good (100ms +/- lag)
> - Blackberry10/PlaybookOS2 is fine (similar to iPad4)
> - Surface WinRT - SVG Filters are fast - about 100ms +/- delay for the
> filters in Microsoft's test drive
> - Chrome Mobile on Samsung Galaxy Note 2 (running 4.1) - very slow (if I
> can get them to appear at all.) <animate> on turbulence looks like it's
> about 15fps.
>


It looks like we're far off from getting 60fps :-(
Did you try the shorthand filters in Safari? Those should be very fast and
an indication what we can achieve by accelerating SVG filters.


>
>

>
>>  and not "cool" enough (i.e. we could add some more fast + interesting
>> operations... before requiring people to go to CSS Shaders).
>>
>> I think we have a quite balanced set of shorthand filters for the first
>> level of this specification. I am sure that we can find a lot more
>> interesting effects that are worth adding once browsers ship with the
>> current filters. I would like to track them separately.
>
>
>
>>
>> Greetings,
>> Dirk
>>
>> >
>> > Dean
>> >
>> >
>> > On 31/03/2013, at 1: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/
>> >
>>
>>
>>
>