[whatwg] Enabling LCD Text and antialiasing in canvas
senorblanco at chromium.org
Wed Feb 13 11:25:22 PST 2013
On Wed, Feb 13, 2013 at 12:22 PM, Rik Cabanier <cabanier at 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  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.)
More information about the whatwg