On Wed, Apr 3, 2013 at 5:21 PM, Gregg Tavares <g...@google.com> wrote:
> > > > On Wed, Apr 3, 2013 at 5:09 PM, James Robinson <jam...@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 <g...@google.com> wrote: >> >>> On Wed, Apr 3, 2013 at 5:04 PM, Rik Cabanier <caban...@gmail.com> wrote: >>> >>> > >>> > >>> > On Wed, Apr 3, 2013 at 9:04 AM, Gregg Tavares <g...@google.com> wrote: >>> > >>> >> On Wed, Apr 3, 2013 at 8:41 AM, Stephen White < >>> senorbla...@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 <g...@google.com> >>> >> wrote: >>> >> > >>> >> >> On Sun, Mar 17, 2013 at 1:40 PM, Robert O'Callahan < >>> >> rob...@ocallahan.org >>> >> >> >wrote: >>> >> >> >>> >> >> > On Sat, Mar 16, 2013 at 5:52 PM, Gregg Tavares <g...@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] >>> >> >> > >>> >> >> >>> >> > >>> >> > >>> >> >>> > >>> > >>> >> >> >