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

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.

> 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.

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?

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w