[whatwg] Enabling LCD Text and antialiasing in canvas

[Stephen White]

On Sat, Feb 16, 2013 at 4:12 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> 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.


Even with text on an opaque background, I think you still have to worry
about the case of transformed canvases.  E.g., text drawn over an opaque
background into a single still frame canvas, but then subsequently rotated
via CSS transforms from 0 degrees through non-0.  The first frame can use
subpixel AA, but then subsequent frames can't.  So I think you need to keep
the command stream around (first case) or
always render two buffers as soon as you draw text.  That seems like a
pretty heavy burden.

For canvas->WebGL the problem becomes pretty much intractable, since
there's no way to know what a given shader will do to the pixels.  So I
think you'd always have to give up and do grayscale AA in that case.

Stephen

>
>
> 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]
>