Re: Adding blending to the canvas API

Filters/shaders and blending are very different concepts.
Filters take 1 source and modify the pixels.
Blending operations take 2 sources, blend the pixels and generate a new
image.

I can see that filters and custom shaders can useful but I'm just looking
for feedback on blending at this point.
The simplest way to do this seems to extend the list of compositing
operators and specify that the result of the blend operation is always
composited with src-over.
Since Canvas draws in immediate mode, concepts like grouping are most
likely not going to translate.

Rik

On Thu, Apr 5, 2012 at 5:11 PM, Charles Pritchard <chuck@jumis.com> wrote:

> On 4/5/2012 4:44 PM, Rik Cabanier wrote:
>
>> All,
>>
>> I'm working on a spec to add blending and compositing through simple CSS
>> keywords. A very early draft can be found here:
>> https://dvcs.w3.org/hg/FXTF/**raw-file/tip/compositing/**index.html<https://dvcs.w3.org/hg/FXTF/raw-file/tip/compositing/index.html>as well as a blog post here:
>> http://blogs.adobe.com/**webplatform/2012/04/04/**
>> bringing-blending-to-the-web/<http://blogs.adobe.com/webplatform/2012/04/04/bringing-blending-to-the-web/>
>> It seems that this feature would be useful for Canvas as well. Group
>> isolation and knockout might be hard to implement but they aren't as
>> important as the blending modes themselves.
>>
>> Does anyone think this is value in extending the canvas API so you can
>> set multiply, overlay, etc?
>>
>
> TL;DR: There is value in extending the Canvas API for blend operations.
> The porter-duff operations work well, the shadows module prepared Canvas
> code bases for additional blend modes.
> This seems like an easy win. I'd like to include custom filters in the
> update. It's not such an easy win, but I think it's quite doable.
>
> ...
>
> I've certainly worked with these composting items in Canvas.
> We had to hook into ImageData, of course.
>
> There are two issues that spring to mind:
> a) Do we want to extend the Canvas API further at this point?
>
> My primary concern has been getting implementers to "fix" Canvas
> accessibility. Apart from that,
> clean and clear improvements to canvas are quite welcome.
>
> Hixie has recently proposed a major upgrade to the Canvas API, titled
> Canvas v5.
> We may as well pile-on while he's experimenting with a large rewrite.
>
> b) Do we want to extend the Canvas API to allow custom shaders?
> Flash has allowed custom shaders for some time.
>
> We have three specs we can draw from for complex and custom shaders /
> filters:
> https://dvcs.w3.org/hg/FXTF/**raw-file/tip/custom/index.html<https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html>
> https://dvcs.w3.org/hg/FXTF/**raw-file/tip/filters/index.**html<https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html>
> https://dvcs.w3.org/hg/audio/**raw-file/tip/streams/**
> StreamProcessing.html#worker-**processing<https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html#worker-processing>
>
> An author could setup a CSS chain and use it with Canvas as gracefully as
> using it with other elements:
> filter(hue, url(hue.fs), url(hue.js))
>
> There are times when we as authors would want to use shaders in CSS, and
> there are other times when we want the shaders to actually apply to our
> image data.
>
>
> -Charles
>