[whatwg] Enabling LCD Text and antialiasing in canvas

[Gregg Tavares]

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?

 &




>  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.


>
> - James
>
>
> 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]
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>