[whatwg] Enabling LCD Text and antialiasing in canvas

[Robert O'Callahan]

On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco at chromium.org>wrote:

> deferred canvas rendering (collect commands into a buffer, flush buffer
> only when compositing canvas to page, and decide on subpixel AA at that
> point)
> pro:  catches all cases of color fringing
> con:  in some cases, requires an infinite buffer (e.g., a canvas that
> never clears, and only accumulates drawing frame-to-frame means you must
> accumulate commands indefinitely)
> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
> con:  may introduce performance hit due to re-rendering with and without
> subpixel AA (in cases where you would rather have just gone without)
>
> two buffers (one grayscale, one LCD AA)
> pro:  handles all cases of color fringing
> pro:  moderately easy to implement
> con:  RAM (or VRAM) usage is doubled
> con:  possibly-unnecessary performance hit
> con:  must be opt-in
>

Both of these schemes can actually be optimized some more: As long as no
text is drawn to a canvas, you can freely rasterize (in the first case) or
use just one buffer (in the second case). In fact, this is true as long as
no text is drawn to a canvas over non-opaque pixels. So a lot of canvas
usage could be handled with little or no performance hit.

Rob
-- 
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]