[whatwg] Enabling LCD Text and antialiasing in canvas

[Stephen White]

Here's a first draft of a proposal to standardize moz-opaque.  (Note that
Firefox/Linux and Firefox/Win differ in their implementation of moz-opaque.
 This proposal is most similar to the Firefox/Linux implementation, but
with the canvas cleared to opaque black as in the Firefox/Win version).

Motivation:  Compositing a <canvas> element into the page can be expensive,
due to blending operations, and lack of opportunity for culling.  Since
arbitrary graphics operations can affect the opacity of the canvas, it is
difficult to determine programmatically whether the canvas is opaque.
 Allowing the developer to explicitly mark a canvas as opaque allows the
user agent to optimize blending at page composite time, as well as culling
obscured elements behind the canvas.

Description:

The "opaque" attribute is a boolean attribute of the canvas element, whose
presence indicates that the alpha values in the canvas backing store must
be ignored when compositing the canvas into the page.  If the attribute is
not present, or if parsing its value returns an error, then the default
value (false) must be used instead.

When a canvas has the opaque attribute, the backing store must be
initialized to opaque black (rgba(0, 0, 0, 1.0)), instead of transparent
black (rgba(0, 0, 0, 0.0)).  Changing or removing the attribute after
initialization causes the canvas to be cleared to the appropriate value.

All other canvas functionality behaves as normal, including operations
which modify the alpha values of the backing store.  However, any such
transparency values will be ignored when compositing the canvas into the
page, and the canvas will be treated as if every pixel has an alpha of 1.0.

Stephen


On Fri, Mar 8, 2013 at 6:57 PM, Stephen White <senorblanco at chromium.org>wrote:

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