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

On Wed, Apr 3, 2013 at 12:04 PM, Gregg Tavares <gman@google.com> wrote:

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

I think it would be better to control antialiasing for fonts and paths
independently. In addition to providing greater control, subpixel
antialiasing usually only benefits small, detailed paths such as fonts.
Large paths don't benefit greatly from it.

On a practical level, most platform graphics APIs don't provide subpixel
antialiasing for paths, only for text.  So it would have to be implemented
as a custom path renderer, and it would have to have access to the LCD
subpixel structure and orientation, which many platform APIs may not
provide.

Stephen


>> 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 Thursday, 4 April 2013 00:33:23 UTC