- From: Michael Mullany <michael@sencha.com>
- Date: Mon, 1 Apr 2013 18:30:51 -0700
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: Dean Jackson <dino@apple.com>, "public-fx@w3.org" <public-fx@w3.org>, Alexandru Chiculita <achicu@adobe.com>
- Message-ID: <CABTYPJ=ut31+_JAEvkwLsHH52=2AviB_qkXWyW=rOcHz4nhOaw@mail.gmail.com>
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. > 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/ > > > > >
Received on Tuesday, 2 April 2013 01:31:48 UTC