[whatwg] Enabling LCD Text and antialiasing in canvas

[Rik Cabanier]

On Fri, Feb 22, 2013 at 7: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 Rik is convincing me that we shouldn't expose mozOpaque or any
>>> other explicit subpixel AA control to the Web. It will be very easy for Web
>>> authors to test it in one place and discover that it works without
>>> realizing that they're causing problems for some users.
>>>
>>> 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.
>
> 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?
>
> 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.
>

Since this is a feature for advanced users, we should let them handle all
the cases. (I would even allow subpixel AA on a transparent canvas)
Handling all the edge cases in the browser will be extremely difficult (if
it's even possible) and will just frustrate those advanced users since it
will get in their way.


>
>
>>>
>> Great! I think matteColor (or matteStyle to be more consistent) can
>> easily be implemented. We can optimize rendering later.
>>
>
>> So, if a mattecolor is set the UA can assume that:
>>
>
> 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.
>

Doesn't that seem slightly hacky?
So, if the canvas detects that you did a fillrect with a constant color, it
should assume that it's opaque?  This seems confusing from an author's
perspective.
In addition, compositing modes that introduce alpha will turn the bit off
again and there would be no way to turn it back on.


>
> - all compositing operation within the canvas can ignore background alpha
>> - the canvas can be copied directly to the screen (unless another effect
>> is applied to the canvas element or its ancestor)
>>
>> If mattecolor is set, the UA should matte with that color. If a
>> compositing operation (that introduces alpha) is used, the matte operation
>> needs to be repeated.
>>
>> Rik
>>
>
>