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

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

From: Stephen White <senorblanco@chromium.org>
Date: Thu, 14 Mar 2013 10:20:34 -0400
Message-ID: <CAPeKFTiLQ=Y2NNvNbdcAjbtM7iY8zaOBs5WXogD6iYQzEaX1XA@mail.gmail.com>
To: Gregg Tavares <gman@google.com>
Cc: WHAT Working Group <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Rik Cabanier <cabanier@gmail.com>, Robert O'Callahan <robert@ocallahan.org>
On Wed, Mar 13, 2013 at 10:28 PM, Gregg Tavares <gman@google.com> wrote:

>
>
>
> On Wed, Mar 13, 2013 at 1:18 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> On Thu, Mar 14, 2013 at 8:04 AM, Gregg Tavares <gman@google.com> wrote:
>>
>>> It seems like an opaque canvas should be an orthogonal issue to
>>> subpixel-aa. Subpixel AA seems like it should be a Canvas2DRenderingContext
>>> setting though maybe with a name like
>>>
>>>    ctx.antialiasingRenderQuality =
>>>
>>> With options of
>>>
>>>    none
>>>    grayscale
>>>    bestForDeviceIfAxisAlignedAndNotScaledOrBlended
>>>
>>
> My mistake. They should be
>
>     none
>     alpha
>
> bestForDeviceIfNotCanvasIsNotRotatedAndCanvasIsNotScaledAndCanvasIsOpaque
>

Don't forget
AndCanvasIsNotFilteredAndCanvasIsNotDrawnViaWebGLThroughAShaderWhichModifiesFragmentColour.
 :)

(And actually, this name sort of leads me to believe the opposite:  that
the API will take care of these cases for me, and I don't have to worry
about them.)

Naming aside, this is basically the proposal from message #1 in this thread
(and mine from partway through).  The objections were that this is a
footgun with which web developers should not be trusted.  For the record, I
don't agree with that assessment.  However, since it seemed that moz-opaque
had at least some chance of being implemented by other browser vendors, and
provides a generally useful optimization, I was pursuing that approach
instead.


> Stephen


>
> ;-)
>
> Yes, I know that's a horrible name but it spells out the limitation of the
> higher quality aa needed on some devices. A dev can opt in (Since the
> default is alpha which is what happens today).
>
> If they opt in
>
> (a) it will look good if they follow the rules
>
> and
>
> (b) as the world transitions to HD-DPI it will end up being alpha so it's
> forward compatible.
>
>
>
>
>> Ugh!
>>
>>
>>> This would let the developer choose. It would be clear what the limits
>>> are, when to use it, and would let the developer choose what they need,
>>> even in an opaque canvas.
>>>
>>
>> Then we would need to come up with a spec for what happens when you
>> composite subpixel AA over non-opaque pixels, including how the per-channel
>> alpha values are combined to form a single alpha value. IIRC in some cases
>> (D2D) you just can't do it.
>>
>> If we said that in a non-opaque canvas, subpixel AA is treated as
>> grayscale, that would be OK.
>
>
> sure.
>
>
>>
>>
>> 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 Thursday, 14 March 2013 14:21:08 GMT

This archive was generated by hypermail 2.3.1 : Thursday, 14 March 2013 14:21:09 GMT