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 21:06:48 +0200
Message-ID: <1398884808.12369.34.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 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.

Tav
Received on Wednesday, 30 April 2014 19:07:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:52 UTC