- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 30 Apr 2014 12:59:18 -0700
- To: Tavmjong Bah <tavmjong@free.fr>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, Dirk Schulze <dschulze@adobe.com>, Dean Jackson <dino@apple.com>, FX <public-fx@w3.org>
- Message-ID: <CAGN7qDDyvew_=4CYi1KLxof_dnH7MjkDnb6s1Qqcvty2hsHBDg@mail.gmail.com>
On Wed, Apr 30, 2014 at 12:06 PM, Tavmjong Bah <tavmjong@free.fr> wrote: > 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. > Given this, would you object to splitting out the non-separable blending mode to the next level?
Received on Wednesday, 30 April 2014 19:59:47 UTC