[whatwg] Enabling LCD Text and antialiasing in canvas

[Stephen White]

On Tue, Feb 19, 2013 at 11:31 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> So now we have:
> - don't do this on pinch-zoom devices
> - don't do this for HW accelerated canvases
> - don't do this if the canvas dpi doesn't match the screen
>
- don't do this if there are transforms
> - authors will have to be very careful when using this feature since it
> can turn on or off or cause rendering glitches.
>
> Is it still worth pursuing this?
>

I believe it is.  Even with those constraints, there are a large number of
applications which can benefit from text which looks as good as the native
platform can provide.

That said, I also think Robert is right that we should not spec out
precisely when subpixel AA text will occur in any of these automatic modes,
since:

1)  there are some platforms/devices which don't do LCD text at all
2)  It may be too restrictive for the browser implementor, e.g., they may
be essentially required to implement deferred rendering or two backing
stores in order to meet the resulting spec, which seems onerous

Subpixel AA text aside, I still think it's worth spec'ing out mozOpaque, if
only just for the optimization opportunities that we don't get with an
automatic solution (e.g., putImageData).  Its implementation is fairly
straightforward (much more so than the other options above), and it won't
break any existing content.

To me, the "it breaks compositing" argument falls into the "doctor, it
hurts when I do this" category:  the user is specifically opting into an
opaque backing store, and so the changes in behaviour for compositing modes
which reference destination alpha are expected, just as they are when using
DST_ALPHA blending modes in a WebGL context created with the "alpha"
attribute set to false.

Stephen


>
> On Tue, Feb 19, 2013 at 3:40 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> On Tue, Feb 19, 2013 at 5:19 PM, Stephen White <senorblanco at chromium.org>wrote:
>>
>>> 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.
>>>
>>
>> Yes, you're quite right.
>>
>>
>> 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]
>>
>
>