- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 21 Sep 2012 12:35:52 -0700
- To: Tyler Larson <talltyler@gmail.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
On Fri, Sep 21, 2012 at 8:34 AM, Tyler Larson <talltyler@gmail.com> wrote: > On Sep 21, 2012, at 9:49 AM, Rik Cabanier <cabanier@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, 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. Not true - having useful predefined things *in addition to* lower-level primitives is good for authors. Rik is right that once canvas supports CSS Filters, you can do per-pixel matrix transformations via an SVG <feComponentMatrix> filter. However, you can't yet use SVG filters to do matrix transforms over multiple pixels, like you need to do emboss or blur filters yourself. > 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. Usually, these kinds of things are written as a flat array of components, with each item cycling between being an r, g, b, or a. This is what is already used by ImageData, for example. It seems reasonable in the future to let the functions that take an ImageData also take an ArrayBuffer directly. ~TJ
Received on Friday, 21 September 2012 19:36:45 UTC