Re: [compositing-1] please move non-separable effects to Level 2

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?