[whatwg] Enabling LCD Text and antialiasing in canvas

[Stephen White]

On Sat, Feb 23, 2013 at 6:48 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sat, Feb 23, 2013 at 4:59 AM, Stephen White <senorblanco at chromium.org>wrote:
>
>> On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <
>>> robert at ocallahan.org> wrote:
>>>
>>>> I think a fully automatic solution that tries to use subpixel AA but is
>>>> always able to render grayscale AA if needed is the way to go. Possibly
>>>> with an author hint to suggest opting into a more expensive rendering path.
>>>
>>>
>> Here are the problems I see with that approach:
>>
>> 1)  In order to avoid a performance hit for existing content, it still
>> requires a spec change (the hint)
>> 2)  Even with the hint, when the author knows they want LCD AA, they
>> still incur a performance penalty of drawing to two buffers.
>> 3)  It still can't handle all cases, such as canvas -> WebGL, which will
>> have to remain grayscale-only, even when the author knows it would be safe
>> for their application.
>>
>
> I agree those are problems. All of the available options have problems.
>

Given that that's the case, I am going to move forward with the opaque
attribute, since I feel it is the lesser of all the evils presented thus
far.  Paying the cost of two buffers and double-rendering just isn't
palatable, IMHO.


>  Also, what form should this authoring hint take?  Is it going to
>> explicitly call out LCD AA?  In that case, how is it better than an opt-in
>> canvas attribute?  If it doesn't explicitly call out LCD AA, but that's the
>> only effect it has, what should it be called?
>>
>
> Perhaps we could use "text-rendering:optimizeLegibility" on the canvas
> element.
>

We also might be over-thinking the danger that LCD AA poses.

Firefox/Linux and Firefox/Mac are both currently shipping with LCD AA
turned on unconditionally in <canvas>, and it's trivial to make them expose
color fringing.  WebKit nightlies (Safari build) seem do the same, although
Safari 6.0 doesn't.

Stephen


>  I also have concerns that the knowledge of when it's safe to use the LCD
>> AA buffer is going to spread throughout the browser codebase, even in areas
>> which currently have no knowledge of canvas, in order to handle all the
>> special cases.  This may just be an implementation detail (and may be
>> avoidable, this is TBD), but it does have the potential to introduce
>> dependencies or complicate implementation.
>>
>
> Maybe.
>
>
> Maybe I'm missing something, but if we're going down the automatic road,
>> why do we need a new function/attribute?  Why not simply detect when a
>> canvas-sized fillRect() has been performed with an opaque fillStyle?  This
>> would also allow optimization of existing content.
>
>
> I agree.
>
> 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]
>