[whatwg] [canvas] matrix based changes on bitmaps

Tyler Larson talltyler at gmail.com
Fri Sep 21 08:34:19 PDT 2012


On Sep 21, 2012, at 9:49 AM, Rik Cabanier <cabanier at gmail.com> wrote:
> Support CSS Filters will satisfy this use case.
> There are a number of built-in filters (such as sepia and constrast) and even support for vertex and fragment shaders.
> The current spec doesn't have a shorthand for the generic 'matrix' but it allows you to refer to an SVG filter where there is support for this.
> 
> Rik

Rik, If we had access to matrix transformation on the pixels we wouldn't need a sepia or contrast methods, all of this could be created as a simple transform. 

On Sep 21, 2012, at 3:34 AM, Jussi Kalliokoski <jussi.kalliokoski at gmail.com> wrote:
> Please see the DSP API [1]. It's currently developed unofficially under the W3C Audio WG [2], so if you have input, please post it to the audiowg public mailing list. This should scratch your itch and more. ;)
> 
> Cheers,
> Jussi
> 
> [1] http://people.opera.com/mage/dspapi/
> [2] http://www.w3.org/2011/audio/


This stuff looks really interesting, and actually lower level than I was asking for which is cool but I'm not sure how this could be abstracted out so that it is useful for things outside of Audio? I'm likely just not putting it all together.

> It seems like a reasonable suggestion, but since the pixel data is 
> available as an ArrayBuffer, it seems like the more reasonable thing to do 
> is to provide generic ArrayBuffer manipulation routines.
> 
> I recommend raising this as feedback on the ArrayBuffer spec.

I like the idea of abstracting this into an ArrayBuffer, I like the sound of this but ArrayBuffers seem to promote nested arrays, where as the Canvas spec uses a simpler structure with r,g,b,a,… pixel values. It would be awesome to have these types of inconsistencies worked out so we didn't need to transform our data into different structures before applying it. 

An abstraction between all of these contexts (Canvas,Element Transforms,Audio,WebGL,...) seems doable but if it means sacrificing performance later because what is output by the generic structure can't be used in each of these APIs as is, I would rather have more targeted transformation methods on each of these APIs. 

-Tyler




More information about the whatwg mailing list