W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2014

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

From: Tavmjong Bah <tavmjong@free.fr>
Date: Wed, 30 Apr 2014 20:50:41 +0200
Message-ID: <1398883841.12369.27.camel@localhost.localdomain>
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 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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:49 UTC