[whatwg] Enabling LCD Text and antialiasing in canvas

[Rik Cabanier]

On Wed, Apr 3, 2013 at 5:21 PM, Gregg Tavares <gman at google.com> wrote:

>
>
>
> On Wed, Apr 3, 2013 at 5:09 PM, James Robinson <jamesr at google.com> wrote:
>
>> Fonts are not vector art
>>
>
> O RLY?   So you're saying the following 250pt ampersand is stored as a
> bitmap in the font file?
>
>  &
>
>
It's not simply stored as a path that you then scale. In some fonts it
might be in a completely different format than a path (or it could even be
a bitmap)


>
>
>
>>  and are not rendered as paths at commonly read sizes.  I don't think
>> anyone is using or would be tempted to use LCD subpixel AA for anything
>> other than text.
>>
>
> I think google docs, as one example, would be happy to have graphs in
> spreadsheets and drawings looks a beautiful as possible.
>
> Why do you think the AA hint should be overly specific? I don't see the
> downside.
>

Fonts render different from paths. If your UA doesn't do that, you are
doing it wrong. :-)
Line art looks different to the human eye than a line of text. Imagina a
vertical and a horizontal line rendered with sub-pixel AA; they will look
very different.

Text also has the nice property that it's filled with a solid color. If you
do subpixel AA on a gradient, the edge will change position   which is very
wrong.


>
>
>>
>>
>> On Wed, Apr 3, 2013 at 5:07 PM, Gregg Tavares <gman at google.com> wrote:
>>
>>> On Wed, Apr 3, 2013 at 5:04 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>>
>>> >
>>> >
>>> > On Wed, Apr 3, 2013 at 9:04 AM, Gregg Tavares <gman at google.com> wrote:
>>> >
>>> >> On Wed, Apr 3, 2013 at 8:41 AM, Stephen White <
>>> senorblanco at chromium.org
>>> >> >wrote:
>>> >>
>>> >> > Would Mozilla (or other browser vendors) be interested in
>>> implementing
>>> >> the
>>> >> > hint as Gregg described above?
>>> >> >
>>> >> > If so, we could break out the LCD text issue from canvas opacity,
>>> and
>>> >> > consider the latter on its own merits, since it has benefits apart
>>> from
>>> >> LCD
>>> >> > text (i.e., performance). Regarding that, if I'm reading correctly,
>>> >> > Vladimir Vukicevic has expressed support on webkit-dev for the
>>> >> > ctx.getContext('2d', { alpha: false }) proposal (basically, a
>>> syntactic
>>> >> > rewrite of <canvas opaque>). Does this indeed have traction with
>>> other
>>> >> > browser vendors?
>>> >> >
>>> >> > As for naming, I would prefer that it be something like
>>> >> ctx.fontSmoothing
>>> >> > or ctx.fontSmoothingHint, to align more closely with canvas's
>>> >> > ctx.imageSmoothingEnabled and webkit's -webkit-font-smoothing CSS
>>> >> property.
>>> >> >  -webkit-font-smoothing has "none", "antialiased" and
>>> >> > "subpixel-antialiased" as options. I think it's ok to explicitly
>>> call
>>> >> out
>>> >> > subpixel antialiasing, even if the platform (or UA) does not
>>> support it,
>>> >> > especially if the attribute explicitly describes itself as a hint.
>>> >> >
>>> >>
>>> >>
>>> >> Why call it "Font" smoothing? Shouldn't a UA be able to also render
>>> paths
>>> >> using the same hint?
>>> >>
>>> >
>>> > I have not heard of anyone using sub-pixel antialiasing for vector
>>> art. It
>>> > might look weird...
>>> >
>>>
>>> ??? Fonts are vector art.  Why should this flag be specific to fonts?
>>>  So I
>>> decide tomorrow that I want vector art to be prettier than the
>>> competition
>>> in by implementing LCD anti-aliasing I'll have to lobby for a new flag to
>>> turn it on? Why?
>>>
>>>
>>>
>>>
>>> >
>>> >
>>> >>
>>> >>
>>> >> >
>>> >> > Stephen
>>> >> >
>>> >> >
>>> >> > On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares <gman at google.com>
>>> >> wrote:
>>> >> >
>>> >> >> On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan <
>>> >> robert at ocallahan.org
>>> >> >> >wrote:
>>> >> >>
>>> >> >> > On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares <gman at google.com>
>>> >> wrote:
>>> >> >> >
>>> >> >> >> Let me ask again in a different way ;-)  Specifically about LCD
>>> >> style
>>> >> >> >> antialiasing.
>>> >> >> >>
>>> >> >> >> What about a context attribute "antialiasRenderingQualityHint"
>>> for
>>> >> now
>>> >> >> >> with
>>> >> >> >> 2 settings "default" and "displayDependent"
>>> >> >> >>
>>> >> >> >>    context.antialiasRenderingQualityHint = "displayDependent"
>>> >> >> >>
>>> >> >> >
>>> >> >> > How would this interact with canvas opacity? E.g. if the author
>>> uses
>>> >> >> > displayDependent and then draws text over transparent pixels in
>>> the
>>> >> >> canvas,
>>> >> >> > what is the UA supposed to do?
>>> >> >> >
>>> >> >>
>>> >> >> Whatever the UA wants. It's a hint. From my POV, since the spec
>>> doesn't
>>> >> >> say
>>> >> >> anything about anti-aliasing then it really doesn't matter.
>>> >> >>
>>> >> >> My preference, if I was programming a UA, would be if the user sets
>>> >> >> "displayDependent" and the UA is running on a lo-dpi machine I'd
>>> >> >> unconditionally render LCD-AA with the assumption that the canvas
>>> is
>>> >> >> composited on white. If they want some other color they'd fill the
>>> >> canvas
>>> >> >> with as solid color first. Personally I don't think that needs to
>>> be
>>> >> >> specced, but it would be my suggestion. As I mentioned, even
>>> without
>>> >> this
>>> >> >> hint the spec doesn't prevent a UA from unconditionally using
>>> LCD-AA.
>>> >> >>
>>> >> >> Very few developers are going to run into issues. Most developers
>>> that
>>> >> use
>>> >> >> canvas aren't going to set the hint. Most developers that use
>>> canvas
>>> >> dont'
>>> >> >> make it transparent nor do they CSS rotate/scale them. For those
>>> few
>>> >> >> developers that do happen to blend and/or rotate/scale AND set the
>>> hint
>>> >> >> they'll get probably get some fringing but there (a) there was no
>>> >> >> guarantee
>>> >> >> they wouldn't already have that problem since as pointed out, the
>>> spec
>>> >> >> doesn't specify AA nor what kind, and (b) if they care they'll
>>> either
>>> >> stop
>>> >> >> using the hint or they'll search for "why is my canvas fringy" and
>>> the
>>> >> >> answer will pop up on stackoverlow and they can choose one of the
>>> >> >> solutions.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> >
>>> >> >> > 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]
>>> >> >> >
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>