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

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

From: Gregg Tavares <gman@google.com>
Date: Wed, 3 Apr 2013 09:04:08 -0700
Message-ID: <CAKZ+BNpEcZnVqHiLeKPYEz8O=_ZP9h8DczMrOQguWg3-nzmyFA@mail.gmail.com>
To: Stephen White <senorblanco@chromium.org>
Cc: WHATWG <whatwg@lists.whatwg.org>, Robert O'Callahan <robert@ocallahan.org>
On Wed, Apr 3, 2013 at 8:41 AM, Stephen White <senorblanco@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?


>
> Stephen
>
>
> On Sun, Mar 17, 2013 at 11:17 PM, Gregg Tavares <gman@google.com> wrote:
>
>> On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan <robert@ocallahan.org
>> >wrote:
>>
>> > On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares <gman@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]
>> >
>>
>
>
Received on Wednesday, 3 April 2013 16:04:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:57 UTC