W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2013

Re: [whatwg] Enabling LCD Text and antialiasing in canvas

From: Stephen White <senorblanco@chromium.org>
Date: Fri, 22 Feb 2013 10:59:48 -0500
Message-ID: <CAPeKFTiVrKfzTZOCvshynH3yUyDePz+6ObJpjYGGvLOj_630CA@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: whatwg@whatwg.org, Ian Hickson <ian@hixie.ch>, robert@ocallahan.org
On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <robert@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.


>>
> 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.
>
> Rik
>
Received on Friday, 22 February 2013 16:00:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:19 UTC