[CEF 2171] Significant decrease in font quality on Windows

[peterflynn]

I know Chrome has been going through some major font rendering changes on Windows, to try to align better with native ClearType rendering. I'm not sure if that's landed yet or if there's some other explanation. But this is definitely a step backward in visual quality:

The changes that I can see include:

1. Text is visibly fuzzier. It's especially noticeable on straight vertical lines, like l, b, { -- where it should be perfectly pixel snapped, but instead is usually smeared across two columns of pixels.
2. Antialising is grayscale instead of LCD/ClearType
3. Characters are more colorful -- I think this is just reverting to how colorful they looked before our last CEF update.
4. Characters are a tiny bit larger: at 1920x1080, you lose about 1 line vertically and 3 chars horizontally from the viewport.

I think (1) is a blocker, (2) is something we could live with, and (3)-(4) are no big deal.

[peterflynn]

Unfortunately, the same bug occurs in-browser. Chrome does use subpixel AA for me on other sites like GitHub though, including on dark backgrounds... so I'm beginning to wonder if this could be a problem specific to our webfont (or maybe just all webfonts in general?).

[peterflynn]

Hmm, the plot thickens:

• I removed -webkit-font-smoothing: antialiased; from our body rule in brackets.less
• I switched the code editor font to Consolas, a native non-webfont available on Windows
• I switched the UI font to "Helvetica Neue", Helvetica, Arial

Yet still, both in CEF 2171 and in browser, I'm still seeing the fuzzy grayscale AA. So this may be a CSS problem on our end afterall, since other sites with the same font show better AA both in CEF and in browser.

[peterflynn]

Aha! I was able to build up a small testcase that shows grayscale AA in-browser: http://jsfiddle.net/x7djdghw/1/. If you remove the -webkit-transform: translateZ(0) rotate(90deg); on the triangle icon (or just remove the translateZ part), all the text switches back to subpixel AA.

It seems like as soon as Chrome sees a 3D transform, it now kicks over the whole UI to grayscale AA :-(

Edit: extremely minimal testcase -- http://jsfiddle.net/x7djdghw/3/

- no translateZ
- with translateZ(0)
- dev tools shows div as a separate compositing layer, so it's unclear why it would affect text not on that layer

[peterflynn]

Ok, so it's definitely something about our UI content that's causing this. It's not related to any specific font, since the same font AAs fine in other contexts. For example... using Consolas as the editor font:

- Brackets running in Chrome: crappy gray AA
- a JSFiddle with same font styles: correct subpixel AA
- same fiddle loaded in brackets-shell with CEF 2171: also correct subpixel AA
- Brackets in master's CEF: different, but also has subpixel AA

Larger:

[le717]

@peterflynn If you've traced the issue to a translateZ property, I do know at least two exist on the split view icon, added in #9506.

[peterflynn]

@le717 Unfortunately, even after removing every translateZ in our codebase, the bug still happens. There are other things that trigger a GPU layer in Blink too, so it's possible that any such trigger would have the same effect. I'm trying to contact some Chromium developers to try to find out more.

[le717]

I'd think the loading spinner animation and any transitions/other animations might enable the GPU too.

[peterflynn]

Update: subpixel AA works fine if I load Brackets in IE 10. Definitely a Chrome-specific issue.

The simple testcase with translateZ above is one easy way to repro this, but it seems as if there must be other things that also trigger it since the bug keeps happening in the full Brackets UI even with all occurrences of translateZ commented out. I've posted a Chromium bug with the translateZ repro case plus a question about what other types of things might trigger this: https://code.google.com/p/chromium/issues/detail?id=435497.

[le717]

@peterflynn This might just be a Chrome bug after all. Someone merged your issue into https://code.google.com/p/chromium/issues/detail?id=435317

According to the report, the issue repos in Chrome 37-39 as a regression, and seems to have something to do with translateZ and position: relative.

[peterflynn]

Ok, so it turns out my Chromium bug report may be a red herring for Brackets. It looks like all we need to do is turn off the backface-visibility styles on html, body in order to generally restore full subpixel AA to the UI. Even content neighboring translateZ(0) items, despite that Cr bug, still seems to retain full subpixel AA.

There are still some rendering differences (e.g. text takes up a tad more space), but in general it looks good enough to me.

[peterflynn]

Note: all the -webkit-font-smoothing: antialiased; styles in our CSS are definitely a red herring -- I'd forgotten that's a Mac-specific CSS property (as noted here) and is ignored on all other platforms. Luckily, on Windows there's much less of a weight difference between gray AA & subpixel AA than there is on Mac, so no equivalent "animation text flicker" fix is needed anyway.

[RaymondLim]

Removing Development, PICK ME UP, and fix in progress labels since I just merged the pull request that fixes the issue in Brackets.

[RaymondLim]

Actually, we don't need to wait for the fix for Chromium issue. Closing.