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

On Fri, Apr 18, 2014 at 11: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?


roc means that if a blend mode is not supported on the GPU, gecko would
pick the software compositing mode instead of just dropping the blend mode.


> >
> > 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. SVG Filters
> are also not accelerated in WebKit yet.
>
> If there is implementation feedback that a feature can not be implemented,
> why shouldn’t we reflect that in the spec? After all, interoperability in
> feature support is an important factor for W3C specs. For FX specs we need
> two implementations supporting each feature.
>
> I think this is a very good justification to object to a feature being in
> the spec, not for keeping it in the spec.
>

I believe so too.