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

On Fri, Apr 18, 2014 at 11:09 PM, Dean Jackson <dino@apple.com> wrote:

>
> On 18 Apr 2014, at 10:45 pm, 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.
>
>
> Sometimes that performance degradation might be unacceptable to our users.
> That is, we might be penalising existing features (such as video playback)
> because a new feature comes along, even when it has not yet demonstrated
> its usefulness.
>

Yes, the Safari team is very sensitive on performance.
There are good use cases for the blending modes. I will work on some
examples.

> 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”).
>
>
> That’s right.
>
> I’d also say that people don’t use SVG filters on the Web because they are
> horribly slow. Providing full hardware acceleration for them is possible,
> but not easy. Meanwhile we see people use the shorthand filters exactly
> because they are fast.
>
> So yeah, we don’t want to add things to WebKit until we know we can make
> them fast.
>
> Some more background on the non-separable modes:
>
> - Now that Rik has clarified that they are supported in Adobe products,
> it’s worth noting that Photoshop and Illustrator are not interactive Web
> content that has to run well on a range of devices.
>

To clarify my confusion, the non-sep blend modes in CMYK are weird because
they convert the content to RGB, blend in RGB and then convert it back to
CMYK. They don't work directly on CMYK (and we recommend people don't use
them for prepress)


> - Non-separable modes are not supported by default in OpenGL
> (glBlendFunc). There are some extensions available on some hardware to
> expose them, but these are recent proposals (see [1]). Otherwise you’re
> going to have to do color format conversion in and out.
>
> Anyway, I think we’ve gone as far as we can with this discussion. I’m
> going to add the prefix back in WebKit while the spec includes those modes
> and we don’t support them.
>
> [1] http://www.slideshare.net/Mark_Kilgard/blend-modes-for-opengl
>
> Dean
>
>