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

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.