[whatwg] Enabling LCD Text and antialiasing in canvas
cabanier at gmail.com
Fri Feb 22 16:53:29 PST 2013
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.
> - 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.
More information about the whatwg