Bug 100551 – turn off text antialiasing by default for Chromium Mac DRT

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Tools / Tests

[Dirk Pranke]

currently we turn off text antialiasing by default for Chromium DRT on Windows, but not on the Mac (or Linux, I don't think). I believe this is probably a major source of version-specific pixel-test differences, as lots of tests render differently on different versions of Mac OS because text is antialiases slightly differently by default.

I can see little benefit to using the default text aliasing for tests that don't care about how the text is drawn, and that's most of them. As long as we can enable it for tests that do actually care, it seems reasonable to default to it being off. 

Anyone object?

[Tony Chang]

For Linux, do you mean if we turn it off we'll be able to match Windows' pixel results?  Or are you trying to avoid pixel test churn when we switch from Lucid to Precise?

[Ojan Vafai]

Sounds worth trying. How do we decide which tests care?

[Ojan Vafai]

Would be good to have a sense of roughly how many results we'd be able to share as a result of this.

[Nico Weber]

Fine with me, but I'd check how many baseline images this would deduplicate before doing it.

[Dirk Pranke]

(In reply to comment #1)
> For Linux, do you mean if we turn it off we'll be able to match Windows' pixel results?  Or are you trying to avoid pixel test churn when we switch from Lucid to Precise?

The latter. I have no real reason to think that we'd match windows results (and I don't even know if this matters on Lucid/Precise so much, I haven't even run Precise yet to see).

[Dirk Pranke]

(In reply to comment #2)
> Sounds worth trying. How do we decide which tests care?

I would start by assuming that the ones that care specify a value for -webkit-font-smoothing explicitly and then see if any jumped out at me when I reviewed all the new unsmoothed baselines.

(In reply to comment #3)
> Would be good to have a sense of roughly how many results we'd be able to share as a result of this.

(In reply to comment #4)
> Fine with me, but I'd check how many baseline images this would deduplicate before doing it.

my thinking was to turn it off locally, generate a new set of baselines (on either Lion or ML), and then run both Lion and ML and see if all the tests continue to pass with the new anti-aliased baselines (or at least see how many can be shared).

This would give us an idea of how many will be de-duped and if it's worth it.

Please don't rely on -webkit-font-smoothing for anything. It should have been named -coregraphics-font-smoothing as it is just a hack to expose a CoreGraphics API. The only reason anyone on the web uses it is to turn off glyph outline dilation of lcd smoothed glyphs on Mac (no one cares if it turns off subpixel rendering or not). See http://lists.w3.org/Archives/Public/www-style/2012Oct/0109.html for more explanation. I don't believe Chromium supports it on any platform but Mac, and it shouldn't.

Also, if you're trying to reduce the number of baselines per platform, there should be some means to force the vast majority of text which isn't testing text per-se to use a set of font files we control. Apple has, in the recent past, tweaked some outlines and metrics of the Times Roman it installs on Mac, resulting in changes to text for that reason alone.

[Tony Chang]

(In reply to comment #5)
> The latter. I have no real reason to think that we'd match windows results (and I don't even know if this matters on Lucid/Precise so much, I haven't even run Precise yet to see).

I don't know how much this matters on Lucid/Precise either.  When we switched from Hardy to Lucid, I think I only rebased like 20 tests.  But I think others have tried to run tests on Precise and almost every test with text fails.

I'm a bit skeptical that this will matter since changes to fontconfig or freetype are what caused the failures during the last OS update.

Anyway, if this works, then it seems like it'd be worthwhile on Linux.  There are some layout tests that test hinting and other font config settings in platform/chromium-linux/fast/text.

[Dirk Pranke]

(In reply to comment #7)
> Please don't rely on -webkit-font-smoothing for anything. It should have been named -coregraphics-font-smoothing as it is just a hack to expose a CoreGraphics API. The only reason anyone on the web uses it is to turn off glyph outline dilation of lcd smoothed glyphs on Mac (no one cares if it turns off subpixel rendering or not). See http://lists.w3.org/Archives/Public/www-style/2012Oct/0109.html for more explanation. I don't believe Chromium supports it on any platform but Mac, and it shouldn't.
>

The point is that we rely on webkit-font-smoothing today already in the tests. I think we will probably need to continue to do so indefinitely into the future (or replace it by equivalent testRunner mechanisms). Also, per conversation w/ dglazkov earlier today, I was under the impression that it does also do something on Win and Linux?
 
> Also, if you're trying to reduce the number of baselines per platform, there should be some means to force the vast majority of text which isn't testing text per-se to use a set of font files we control. Apple has, in the recent past, tweaked some outlines and metrics of the Times Roman it installs on Mac, resulting in changes to text for that reason alone.

That seems like a good suggestion, but I'm not sure how much it helps. It would insulate us against the change you cite, but not changes to how we render a given font generally, or against cross-platform 
changes in font rendering.

(Note that we do tend to require a given set of fonts to be installed already to partially address this).

Other suggestions of course include converting more tests to ref tests and doing other things to mask out text differences that we might not care about (like doing chroma-keying to make out text that isn't red or green, for example).

[Dirk Pranke]

(In reply to comment #8)
> (In reply to comment #5)
> > The latter. I have no real reason to think that we'd match windows results (and I don't even know if this matters on Lucid/Precise so much, I haven't even run Precise yet to see).
> 
> I don't know how much this matters on Lucid/Precise either.  When we switched from Hardy to Lucid, I think I only rebased like 20 tests.  But I think others have tried to run tests on Precise and almost every test with text fails.
> 

Yeah, I recally the Hardy->Lucid transition was not a big deal. We can certainly evaluate this one platform at a time.

[James Robinson]

Apple Mac DRT disables font smoothing by default here:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Tools/DumpRenderTree/mac/DumpRenderTree.mm&q=NSUserDefaults%20Tools&sq=package:chromium&type=cs&l=588

[defaults setInteger:NoFontSmoothing forKey:@"AppleFontSmoothing"];

[Nico Weber]

Turns out skia does turn off lcd antialiasing in SkFontHost_mac_coretext if layout test mode is set, see https://codereview.chromium.org/12316132 and https://bugs.webkit.org/show_bug.cgi?id=110890

So at least on Mac, we probably don't want to do this (since skia already does it). This might be true on linux too.

Text pixel baselines on mac seem to match on 10.6, .7, and .8.

[James Robinson]

(In reply to comment #12)
> Turns out skia does turn off lcd antialiasing in SkFontHost_mac_coretext if layout test mode is set, see https://codereview.chromium.org/12316132 and https://bugs.webkit.org/show_bug.cgi?id=110890
> 
> So at least on Mac, we probably don't want to do this (since skia already does it). This might be true on linux too.
> 
> Text pixel baselines on mac seem to match on 10.6, .7, and .8.

We get different behavior on Mountain Lion if the test sets -webkit-font-smoothing: none.  We've seen on some tests the edges of Ahem glyphs look different.

[Nico Weber]

(In reply to comment #13)
> (In reply to comment #12)
> > Turns out skia does turn off lcd antialiasing in SkFontHost_mac_coretext if layout test mode is set, see https://codereview.chromium.org/12316132 and https://bugs.webkit.org/show_bug.cgi?id=110890
> > 
> > So at least on Mac, we probably don't want to do this (since skia already does it). This might be true on linux too.
> > 
> > Text pixel baselines on mac seem to match on 10.6, .7, and .8.
> 
> We get different behavior on Mountain Lion if the test sets -webkit-font-smoothing: none.  We've seen on some tests the edges of Ahem glyphs look different.

In third_party/skia/src/ports/SkFontHost_mac.cpp: Offscreen::getCG(), the parameter generateA8FromLCD
 is effectively set in layout test mode. The function has this test:

    // FIXME: lcd smoothed un-hinted rasterization unsupported.
    if (!generateA8FromLCD && SkMask::kA8_Format == glyph.fMaskFormat) {
        doLCD = false;
        doAA = true;
    }

So skia's stuff only works for A8 pixels. -webkit-font-smoothing probably switches glyphs to something else.

[Dirk Pranke]

so, when I did all the work moving from Lucid to Precise, I didn't see a lot of diffs that looked like they were the result of changes to antialiasing algorithms, so I suspect this is less useful for Linux.

Also, given the "custom freetype" approach, this is also less needed on Linux.

So, I'm retitling this to mac-only for now.

[Nico Weber]

wontfix per comment 12 then.

[James Robinson]

(In reply to comment #16)
> wontfix per comment 12 then.

What?  That doesn't make any sense.

[Dirk Pranke]

(In reply to comment #17)
> (In reply to comment #16)
> > wontfix per comment 12 then.
> 
> What?  That doesn't make any sense.

Virtually every pixel test w/ text in it is different on .7 and .8. Nico, what are you basing comment #12 on?

[Nico Weber]

> Virtually every pixel test w/ text in it is different on .7 and .8. Nico, what are you basing comment #12 on?

I tried a few tests which pass locally for me, with the same baseline on 10.6 and 10.8. Sounds like that's not representative.

…anyway, if someone does what's suggested in comment 11, note that I tried doing this in content shell drt and read the changes linked from comment 12 before moving ahead.

So I'm rather confused by some of the statements here and will add my two cents.

(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > Turns out skia does turn off lcd antialiasing in SkFontHost_mac_coretext if layout test mode is set, see https://codereview.chromium.org/12316132 and https://bugs.webkit.org/show_bug.cgi?id=110890
> > > 
> > > So at least on Mac, we probably don't want to do this (since skia already does it). This might be true on linux too.

I'm not sure what this means? Skia itself has no particular notion of layout test mode, it just draws what it can. Note that on Mac when AppleFontSmoothing is set to 0 (none) CoreGraphics doesn't draw anything with lcd antialiasing, even if specifically requested. So with this setting you aren't going to get lcd smoothing unless you do it yourself (which we currently don't). Note that other platforms (GDI, FreeType, DirectWrite) don't care about any magic system setting and will do what they're asked.

> > > 
> > > Text pixel baselines on mac seem to match on 10.6, .7, and .8.
> > 
> > We get different behavior on Mountain Lion if the test sets -webkit-font-smoothing: none.  We've seen on some tests the edges of Ahem glyphs look different.
> 
> In third_party/skia/src/ports/SkFontHost_mac.cpp: Offscreen::getCG(), the parameter generateA8FromLCD
>  is effectively set in layout test mode. The function has this test:
> 
>     // FIXME: lcd smoothed un-hinted rasterization unsupported.
>     if (!generateA8FromLCD && SkMask::kA8_Format == glyph.fMaskFormat) {
>         doLCD = false;
>         doAA = true;
>     }
> 
> So skia's stuff only works for A8 pixels. -webkit-font-smoothing probably switches glyphs to something else.

-webkit-font-smoothing:antialiased just sets the Skia hinting to 'none', because no one seriously uses it to prevent lcd antialiasing, they set it to get glyphs which haven't had their outlines dilated on Mac (AppleFontSmoothing 1-3 determines which hard-coded dilation percentages to use). CoreGraphics will never produce lcd smoothed glyph rasterizations from un-dilated outlines. Once we get an actual lcd filter into SkScalerContext we can support this by just rasterizing the un-dilated outlines ourselves. Note that generateA8FromLCD just means have CoreGraphics render the lcd smoothed glyph (from its magically dilated outlines) and then back-form an A8 mask from that. So I'm not sure what is meant by 'only works for A8 pixels'.

[Nico Weber]

(In reply to comment #20)
> So I'm rather confused by some of the statements here and will add my two cents.
> 
> (In reply to comment #14)
> > (In reply to comment #13)
> > > (In reply to comment #12)
> > > > Turns out skia does turn off lcd antialiasing in SkFontHost_mac_coretext if layout test mode is set, see https://codereview.chromium.org/12316132 and https://bugs.webkit.org/show_bug.cgi?id=110890
> > > > 
> > > > So at least on Mac, we probably don't want to do this (since skia already does it). This might be true on linux too.
> 
> I'm not sure what this means? Skia itself has no particular notion of layout test mode, it just draws what it can. Note that on Mac when AppleFontSmoothing is set to 0 (none) CoreGraphics doesn't draw anything with lcd antialiasing, even if specifically requested. So with this setting you aren't going to get lcd smoothing unless you do it yourself (which we currently don't). Note that other platforms (GDI, FreeType, DirectWrite) don't care about any magic system setting and will do what they're asked.

third_party/WebKit/Source/WebCore/platform/graphics/skia/FontSkia.cpp has:

    if (!shouldUseSmoothing() || isRunningLayoutTest())
        shouldSmoothFonts = false;

This is later passed to

    paint->setLCDRenderText(shouldSmoothFonts);

which then makes its way to SkFontHost_mac into generateA8FromLCD as described above.

> 
> > > > 
> > > > Text pixel baselines on mac seem to match on 10.6, .7, and .8.
> > > 
> > > We get different behavior on Mountain Lion if the test sets -webkit-font-smoothing: none.  We've seen on some tests the edges of Ahem glyphs look different.
> > 
> > In third_party/skia/src/ports/SkFontHost_mac.cpp: Offscreen::getCG(), the parameter generateA8FromLCD
> >  is effectively set in layout test mode. The function has this test:
> > 
> >     // FIXME: lcd smoothed un-hinted rasterization unsupported.
> >     if (!generateA8FromLCD && SkMask::kA8_Format == glyph.fMaskFormat) {
> >         doLCD = false;
> >         doAA = true;
> >     }
> > 
> > So skia's stuff only works for A8 pixels. -webkit-font-smoothing probably switches glyphs to something else.
> 
> [*snip*] So I'm not sure what is meant by 'only works for A8 pixels'.

I meant the if cited 4 lines above is only entered if SkMask::kA8_Format == glyph.fMaskFormat.