- From: Stephen White <senorblanco@chromium.org>
- Date: Wed, 13 Feb 2013 14:25:22 -0500
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: whatwg@whatwg.org, Ian Hickson <ian@hixie.ch>
On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier@gmail.com> wrote: > For blending optimizations, it might be better to introduce a function > instead of a boolean attribute like 'opaque'. > What you really want, is to matte [1] the canvas with a solid color so you > can optimize compositing. > > How about this API: > > void applyMatte(DOMString color); // color is a CSS rgb color value (alpha > is ignored) > > > When you call this function, the canvas is matted with that color. If it's > the first drawing call, you can just fill the canvas with that color (no > compositing needed) > After matting, you no longer have to read or update the alpha channel > since it's always 1 which should speed up drawing. > Just to be sure we're on the same page, when I mentioned compositing optimizations, I was referring to compositing the canvas backing store into the page, not compositing operations within the canvas itself. One advantage of using an element attribute is that it could be used at backing store allocation time, to allocate RGB instead of RGBA. Forcing a reallocation of the backing store on attribute change would be consistent with changing width and height of the canvas, which have the same effect. Doing so on a context operation would not. If we did use a context function approach as you suggest, how would subpixel AA be handled? Would it be enabled on first call of the function and never disabled? Is there a way to query if the canvas is opaque once it's called? (I'm assuming that all changes to canvas alpha after the first call would have to be ignored, since otherwise you'd have to sniff every operation to see if it affected alpha, and "reset the bit", although perhaps I'm misunderstanding your proposal.) Stephen
Received on Wednesday, 13 February 2013 19:25:52 UTC