On Sat, Feb 23, 2013 at 2:59 AM, Stephen White <senorbla...@chromium.org>wrote:
> On Thu, Feb 21, 2013 at 7:01 PM, Rik Cabanier <caban...@gmail.com> wrote: > >> >> >> On Fri, Feb 22, 2013 at 10:33 AM, Robert O'Callahan <rob...@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.