[whatwg] Enabling LCD Text and antialiasing in canvas

[Rik Cabanier]

On Sat, Feb 23, 2013 at 2: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)
>

What is the performance hit?


> 2)  Even with the hint, when the author knows they want LCD AA, they still
> incur a performance penalty of drawing to two buffers.
>

Why are there 2 buffers? You just draw on top of the existing content. It
is up to the author to ensure correct output.


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

That is OK. A UA is not required to implement this.


>
> 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.
>
>
>>>
>> 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.
>
> Stephen
>
> - 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.
>>
>
I experimented with adding MatteStyle  for Core Graphics in mozilla and
webkit and got the basics of it working.
So, it's definitely possible to add to the browsers.