W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2013

Re: [filter-effects] filters on canvas (was: Re: Proposal: feHSL element (was Re: [filter-effects] hue-rotate() and saturate() filters))

From: Dean Jackson <dino@apple.com>
Date: Sat, 19 Oct 2013 06:09:02 +1100
Cc: Chris Lilley <chris@w3.org>, Rik Cabanier <cabanier@gmail.com>, FX <public-fx@w3.org>
Message-id: <EC29E973-FF89-4046-9EB7-03D63AEB9C67@apple.com>
To: Dirk Schulze <dschulze@adobe.com>

On 19 Oct 2013, at 5:55 am, Dirk Schulze <dschulze@adobe.com> wrote:

>> razy idea: wouldn’t it be cool if the spec had inline JS that
>> manipulated a <canvas> element via ImageBuffer? The spec could also be
>> the reference implementation.)
> We had discussions about a new property for CanvasContext .filter(). Which takes a CSS filter string. Every drawing step would be filtered individually. Just like shadow.
> Another idea was to have a property that takes and ImageData as input, filters it and returns an ImageData object.
> I think the first idea is more powerful and better implementable in HW.
> I am not sure if any of these ideas should go to Filter Effects or to Canvas directly referencing Filter Effects.

I wasn’t being clear. I wasn’t proposing a new feature: I meant the spec could actually do the filter math inline (slowly) on a reference image.

Of course it would rely on the rendering of the canvas element to be color correct, but you could still do getImageData to examine the exact values.

Anyway, I wasn't being serious.

Received on Friday, 18 October 2013 19:09:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:47 UTC