[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:

> On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> Even within canvas, there may be a way to break it if the LCD AA text is
>>> drawn first and a dest-alpha compositing mode is used overtop (I haven't
>>> verified this though).
>>
>>
>> I don't think that's a problem. All destination alpha values will be 1
>> even after the subpixel AA test is painted, and you'll treat it as normal.
>>
>
> I was thinking something like this:
>
> - draw subpixel AA text over an opaque background
> - draw a partially-transparent rect with destination-atop mode over the
> subpixel AA text
>
>  Now some of the subpixel AA text is still there, but the destination
> alpha is non-1, so things will go bad when you composite into the page.
>  (At least I think it will.. Porter-Duff makes my head spin sometimes.)
>

I don't see the problem. After the first step, you have an RGBA buffer that
represents exactly the result of the rendering. The second step treats it
exactly like any other RGBA buffer. Am I being dense?


> The suggestion on the list earlier was to keep two versions of the canvas
>> buffer: one with grayscale AA, another with subpixel AA, and composite with
>> the subpixel AA buffer when we can do that safely, otherwise use the
>> grayscale AA version. In many implementations there would be a performance
>> hit for this, so it would make sense to have authors opt-in to that
>> performance hit.
>>
>
> It would also be a needless performance hit if the developer knew that
> they always wanted subpixel AA, and that their app would never fringe.
>

I don't think the developer can ever know that. They'd have to assume the
browser/platform does not have a quick-zoom feature, which is an assumption
developers shouldn't be making. Although I guess we could just declare that
that case isn't important enough to matter.

So let me take a stab at a brief summary of the proposals so far, and the
> pros and cons of each (correct me if I missed anything):
>
> moz-opaque
> pro:  fairly easy to implement
> pro:  no performance hit over regular rendering
> pro:  many opportunities for optimization
> pro:  catches all in-canvas cases of color fringing
> con:  does not handle any out-of-canvas color fringing
> con:  opt-in
>

Additional con: requires changes to canvas compositing spec and possibly
implementations.


> automatic opacity detection
> pro:  catches most (all?) cases of in-canvas color fringing
> pro:  some opportunties for optimization (must be conservative in some
> cases)
> con:  does not catch color fringing on CSS transforms, canvas -> WebGL, etc
>
> context attribute (something like:  context.textAntialising = { 'none',
> 'grayscale', 'subpixel' })
> pro:  very easy to implement
> pro:  no performance hit
> con:  does not catch any cases of color fringing; completely up to web
> developer
> con:  opt-in
>

Additional con: requires specification and implementation of what happens
when subpixel AA is drawn over transparent background.

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

Not really true, you can just give up on the complex cases and draw
grayscale whenever you feel like it.


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

Sounds right with the above modifications.

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]