- From: Tavmjong Bah <tavmjong@free.fr>
- Date: Wed, 30 Apr 2014 21:06:48 +0200
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: Robert O'Callahan <robert@ocallahan.org>, Dirk Schulze <dschulze@adobe.com>, Dean Jackson <dino@apple.com>, FX <public-fx@w3.org>
On Wed, 2014-04-30 at 11:58 -0700, Rik Cabanier wrote: > > > > On Wed, Apr 30, 2014 at 11:50 AM, Tavmjong Bah <tavmjong@free.fr> > wrote: > On Sat, 2014-04-19 at 21:39 -0700, Rik Cabanier wrote: > > > > > > > > On Sat, Apr 19, 2014 at 7:01 AM, Robert O'Callahan > > <robert@ocallahan.org> wrote: > > On Sat, Apr 19, 2014 at 6:09 PM, Dirk Schulze > > <dschulze@adobe.com> wrote: > > > > On Apr 19, 2014, at 7:45 AM, Robert > O'Callahan > > <robert@ocallahan.org> wrote: > > > > > On Sat, Apr 19, 2014 at 5:38 PM, Dean > Jackson > > <dino@apple.com> wrote: > > > We support them in software mode too, just > not in > > compositing mode. Since we don’t want to > have blending > > disappear if an element becomes composited > (99.9% of > > developers would not be able to explain all > the cases > > in which this could happen), we’d only ship > an > > implementation that supports them > everywhere. > > > > > > In Gecko, blending doesn't disappear, > instead we > > prevent the content from being offloaded to > the > > compositor. So we support them everywhere, > but they > > cause performance degradation in some cases. > > > > > > “Disappear” might not be the right word. > Isolated is > > more correct. Don’t elements get isolated in > Firefox > > when you have opacity, 3D transforms and all > the other > > cases where many implementations currently > have to > > create a compositing layer? > > > > > > I'm not sure what you mean by "isolated" here. AFAIK > we > > properly support isolation as defined in the > compositing spec. > > > > > > > > Yes, Firefox supports isolation and isolates blended content > as > > defined by the spec. > > > > > > > I'll note that Safari 6 release notes > claim support > > for SVG filters. I'm pretty sure you can > implement all > > the blend modes in terms of SVG filters. So > either > > Webkit's SVG filter support is partial (in > which case > > partial support for mix-blend-mode should be > OK too > > right?) or whatever implementation tradeoffs > you made > > for SVG filters you're declining to make for > > mix-blend-mode (which I think is not > accurately > > described as "can't implement”). > > > > > > SVG Filters do not support the > non-separatable blend > > modes. > > > > > > I believe you can implement the blend modes using > SVG filters > > in browsers that support the BackgroundImage > feature. I don't > > know whether Safari 6 implements that or not. > > > > > > > > It does not. > > > > > > If there is implementation feedback that a > feature can > > not be implemented, why shouldn’t we reflect > that in > > the spec? > > > > > > "A feature cannot be implemented" is very ambiguous > language, > > please don't use it. It can mean anything from "it's > > impossible for anyone to implement this feature at > all" to the > > much narrower claim of "Webkit cannot yet make this > feature > > fast in all cases due to internal implementation > issues > > specific to Apple/Webkit". It's clear the former > justifies > > spec changes. I'm not convinced the latter does. > > > > > > > > After all, interoperability in feature > support is an > > important factor for W3C specs. For FX specs > we need > > two implementations supporting each feature. > > > > > > That's a good point that I wish had come up > earlier :-). A > > valid reason to cut something from a spec is to > enable the > > spec to proceed through the W3C process quicker by > having two > > interoperable implementations. Will Blink support > > non-separable blend modes soon enough to prevent > spec progress > > from being blocked? > > > > > > Things are a bit unclear on the blink side. The > implementation there > > is the reverse of gecko: blending is only implemented in the > > compositor and there is no support to do it solely in > software. There > > was some back-and-forth on the blink mailing list and it was > decided > > to halt our efforts until their engineering side has more > free > > cycles. > > > > > > It doesn't really matter though since to exit CR, the two > > interoperable implementations have to be independent and > we've been > > involved in all three. IE is our hope for the second > implementation. > > > For SVG, Inkscape trunk supports rendering of all blend modes > with > isolation. > > > That's an interesting point. Do you believe that Inkscape counts as an > implementation? Why wouldn't it? For SVG 1.1 we submitted an implementation report as did Abbra, Apache, and Telecom ParisTech. Tav
Received on Wednesday, 30 April 2014 19:07:23 UTC