[whatwg] Enabling LCD Text and antialiasing in canvas
senorblanco at chromium.org
Fri Mar 8 15:57:02 PST 2013
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
> 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
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.
> 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 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.
> 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]
More information about the whatwg