- From: Dirk Schulze <dschulze@adobe.com>
- Date: Mon, 1 Apr 2013 14:23:49 -0700
- To: Dean Jackson <dino@apple.com>
- CC: "public-fx@w3.org" <public-fx@w3.org>, Alexandru Chiculita <achicu@adobe.com>
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, 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 Monday, 1 April 2013 21:24:17 UTC