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

On Tue, Apr 2, 2013 at 9:58 AM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
> 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.
>

Short hand filters are real-time responsive yes. But IE 10 already shows
what's possible with HW accelerated SVG filters. I put together this filter
as a demo (excuse the frankenstein javascript):

http://www.codepen.io/mullany/pen/yvmgL

This chains together a weighted greyscale (colormatrix), an unsharp mask
(blur + composite), and a (probably inefficient) selective blur (spotlight,
2blurs, colormatrix, 2 composites). Adjusting the sliders for greyscale
weights allows you to see the lag. Adjustments are *real-time* responsive
on a recent WIn8/IE10 laptop, a little laggy but usable on 1 yr old
Mac/Safari6, and take about half a second to respond on Chrome (Mac)
(Firefox is slower). On iPhone 6 - adjustments take about a second to
execute.

Once everyone implements HW acceleration for filters, we'll be able to see
some pretty darn fast stuff.



>
>
>>
>>
>
>>
>>>  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/
>>> >
>>>
>>>
>>>
>>
>