Re: [whatwg] Enabling LCD Text and antialiasing in canvas

On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <senorblanco@chromium.org>wrote:
>
>> Even with these constraints, I don't think we can guarantee that it's
>> safe to use LCD AA text. Once you've drawn with LCD AA text, even if it's
>> safe at the time of drawing, there's no guarantee that it will be safe
>> later.  For instance, if you then drawImage() that canvas rotated into
>> another canvas, or even just full-page-zoom it, you'll see colour fringing.
>> Or apply CSS 2D or 3D transforms. There are also existing apps which use
>> canvas for 2D text glyphs, and then transform and place them rotated in
>> WebGL. Those will show colour fringing.
>
>
> This came up on the list earlier.
>
> 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.)


>  So I'm starting to think that LCD AA text really has to be opt-in, to
>> avoid breaking existing content. By opting it, you're agreeing that these
>> artifacts are acceptable for your app. For example, you know that even if
>> you're going to do a canvas-to-canvas draw, you're always going to draw at
>> 1:1 scale and no rotation.
>>
>
> It's difficult to know that on a mobile browser or any other browser where
> you have some kind of fast zoom UI.
>
> 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.


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

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

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

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

Received on Friday, 15 February 2013 22:09:42 UTC