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

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.

Tav

Received on Wednesday, 30 April 2014 18:51:13 UTC