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

On Mon, Feb 18, 2013 at 4:01 PM, Stephen White <senorblanco@chromium.org>wrote:

> On Sat, Feb 16, 2013 at 4:09 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Sat, Feb 16, 2013 at 11:09 AM, Stephen White <senorblanco@chromium.org
>> > wrote:
>>
>>> On Fri, Feb 15, 2013 at 2:37 PM, Robert O'Callahan <robert@ocallahan.org
>>> > wrote:
>>>
>>>> On Sat, Feb 16, 2013 at 4:35 AM, Stephen White <
>>>> senorblanco@chromium.org> wrote:
>>>>
>>>>> Even within canvas, there may be a way to break it if the LCD AA text
>>>>> is drawn first and a dest-alpha compositing mode is used overtop (I haven't
>>>>> verified this though).
>>>>
>>>>
>>>> I don't think that's a problem. All destination alpha values will be 1
>>>> even after the subpixel AA test is painted, and you'll treat it as normal.
>>>>
>>>
>>>  I was thinking something like this:
>>>
>>> - draw subpixel AA text over an opaque background
>>> - draw a partially-transparent rect with destination-atop mode over the
>>> subpixel AA text
>>>
>>>  Now some of the subpixel AA text is still there, but the destination
>>> alpha is non-1, so things will go bad when you composite into the page.
>>>  (At least I think it will.. Porter-Duff makes my head spin sometimes.)
>>>
>>
>> I don't see the problem. After the first step, you have an RGBA buffer
>> that represents exactly the result of the rendering. The second step treats
>> it exactly like any other RGBA buffer. Am I being dense?
>>
>
> No, it's probably me.  I was thinking that since there was a way to
> introduce non-1 alpha into the backing store after-the-fact, it would break
> the previously-performed subpixel coverage blending.  But perhaps not.
>

If MozOpaque is set or matteColor (or some other property that we can agree
upon), you will be guaranteed that there will never be alpha in the backing
store when you draw the text. We would also need to define under what
compositing modes subpixel AA happens.


>
>
>>
>>> The suggestion on the list earlier was to keep two versions of the
>>>> canvas buffer: one with grayscale AA, another with subpixel AA, and
>>>> composite with the subpixel AA buffer when we can do that safely, otherwise
>>>> use the grayscale AA version. In many implementations there would be a
>>>> performance hit for this, so it would make sense to have authors opt-in to
>>>> that performance hit.
>>>>
>>>
>>> It would also be a needless performance hit if the developer knew that
>>> they always wanted subpixel AA, and that their app would never fringe.
>>>
>>
>> I don't think the developer can ever know that. They'd have to assume the
>> browser/platform does not have a quick-zoom feature, which is an assumption
>> developers shouldn't be making. Although I guess we could just declare that
>> that case isn't important enough to matter.
>>
>
> Well, pretty much all devices that have pinch-zoom today are high-DPI, and
> don't implement subpixel AA.  :)   But no, I don't think that's not a good
> assumption to bake into the web platform.
>
>
>> So let me take a stab at a brief summary of the proposals so far, and the
>>> pros and cons of each (correct me if I missed anything):
>>>
>>> moz-opaque
>>> pro:  fairly easy to implement
>>> pro:  no performance hit over regular rendering
>>> pro:  many opportunities for optimization
>>> pro:  catches all in-canvas cases of color fringing
>>> con:  does not handle any out-of-canvas color fringing
>>> con:  opt-in
>>>
>>
>> Additional con: requires changes to canvas compositing spec and possibly
>> implementations.
>>
>
> Yes, since it's new behaviour it'll require spec changes.  I guess we can
> consider that as part of "con" of being opt-in.
>
> automatic opacity detection
>>> pro:  catches most (all?) cases of in-canvas color fringing
>>> pro:  some opportunties for optimization (must be conservative in some
>>> cases)
>>>
>>  con:  does not catch color fringing on CSS transforms, canvas -> WebGL,
>>> etc
>>>
>>> context attribute (something like:  context.textAntialising = { 'none',
>>> 'grayscale', 'subpixel' })
>>> pro:  very easy to implement
>>> pro:  no performance hit
>>> con:  does not catch any cases of color fringing; completely up to web
>>> developer
>>> con:  opt-in
>>>
>>
>> Additional con: requires specification and implementation of what happens
>> when subpixel AA is drawn over transparent background.
>>
>
>> deferred canvas rendering (collect commands into a buffer, flush buffer
>>> only when compositing canvas to page, and decide on subpixel AA at that
>>> point)
>>> pro:  catches all cases of color fringing
>>> con:  in some cases, requires an infinite buffer (e.g., a canvas that
>>> never clears, and only accumulates drawing frame-to-frame means you must
>>> accumulate commands indefinitely)
>>>
>>
>> Not really true, you can just give up on the complex cases and draw
>> grayscale whenever you feel like it.
>>
>
> And leave the behaviour unspecified, I'm guessing?  Doesn't that least to
> inconsistent behaviour between browsers?  Even within one implementation,
> if you had content whose command stream varied over the maximum buffer
> length threshold, it'd toggle between subpixel and grayscale AA. Not sure
> if this is a case worth worrying about, but it does feel like it's exposing
> more of the implementation that one would like.
>

So basically, this will be a feature for browsers that have no pinch-zoom
and cases where the author is sure that the canvas DPI matches the screen
DPI.
I personally like the look of regular AA text better than subpixel AA text
so I would like a way to turn it off. I guess it would be up to the browser
to make it a preference.


>
>>
>>> con:  difficult to implement (e.g., canvas-to-canvas drawImage(), etc)
>>> con:  may introduce performance hit due to re-rendering with and without
>>> subpixel AA (in cases where you would rather have just gone without)
>>>
>>> two buffers (one grayscale, one LCD AA)
>>> pro:  handles all cases of color fringing
>>> pro:  moderately easy to implement
>>> con:  RAM (or VRAM) usage is doubled
>>> con:  possibly-unnecessary performance hit
>>> con:  must be opt-in
>>>
>>
>> Sounds right with the above modifications.
>
>
>>
>> Rob
>> --
>> Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
>> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
>> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
>> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
>> — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
>> tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
>>
>
>

Received on Tuesday, 19 February 2013 02:53:03 UTC