This issue is reproducible using a retina MacBook Pro.

Thanks for filling the issue...

It seems that the issue is specific to Mac Mojave. As we don't have that particular OS-Mac to test and confirm the issue from TE end. Hence adding Proj-MacMojave label to it.

Thanks...!

mac triage: Help us ccameron@! You're our only hope...

Does Safari do the same on Mojave?

Seek to 28:00 on https://developer.apple.com/videos/play/wwdc2018/209/ -- "if you look at the text in this window, it's basically identical. ... mac0S 10.13 is using this color fringing effect for its font rendering. In macOS 10.14 we no longer use that effect. And this means our text looks great on a much wider variety of panel technologies as well as scaling modes."

Safari on Mojave is immune.

Bumping into untriaged. The question seems to be whether or not we want to do the same as Safari's renderer and ignore the Mojave directive to never use subpixel antialiasing.

Note it's possibly a bug that Safari is still using subpixel AA on Mojave, and that may be changed before final release.

Subpixel antialiasing is no longer available on Mojava. Safari is using greyscale antialiasing.

Developer beta 4 seems to have automatically delegated subpixel antialiasing to greyscale antialiasing.

My assumption is that we'll do what Safari does and use greyscale (which we're effectively doing now as subpixel is mapped to greyscale) but this is really more of a browser UX decision. 

Is there anything else to do here? It sounds like we use the platform-default, which is greyscale antialiasing.

Marking as WontFix -- please reopen if this is incorrect.

Developer beta 5 removed the mapping to greyscale.

I think it’s better to reopen it because the platform-default is no longer greyscale antialiasing and you need to manually configure Chrome to opt in.

reopening - avi@, please figure out how to opt us in per #16 :)

Let's target this for M70, too.

Just updated to the final version of macOS Mojave. The fonts look really weird. Can you fix this ASAP :( 

Huh - Chrome looks really "washed out" under Mojave on UI Elements like Tab or Bookmarks Bar Font and web content :-(

However, the Omnibox font is more darker and sharper then the Bookmarks Bar or Tab Font.

Is this issue only regarding web content or will this also address the UI Elements?

Deleted: Bildschirmfoto 2018-09-24 um 21.14.06.png 62.5 KB

	Bildschirmfoto 2018-09-24 um 21.14.06.png 62.5 KB View Download

Here is a comparison between Mojave and High Sierra.

Deleted: Bildschirmfoto 2018-09-24 um 21.11.03.png 140 KB

	Bildschirmfoto 2018-09-24 um 21.11.03.png 140 KB View Download

The font in the tabs in noticeably lighter, and this is on a Macbook Pro 2018 which supposedly has a Retina screen that is unaffected by the removal of subpixel antialiasing. The flags for setting greyscale antialiasing have no effect.

The usability difference is quite noticeable, and even if the average user can't consciously understand why Chrome looks different, I would say this is a significant impact on user comfort. 

Deleted: Screen Shot 2018-09-24 at 3.31.41 PM.png 233 KB

	Screen Shot 2018-09-24 at 3.31.41 PM.png 233 KB View Download

It looks like the issue is with supports_LCD(): https://skia.googlesource.com/skia/+/7b562291a7acb65e51ff12f69fef2848471d3456/src/ports/SkFontHost_mac.cpp#375

It currently tests whether LCD font smoothing is on system-wide by drawing some text and then looking for non-gray pixels! On Mojave, LCD smoothing is now grayscale, too. We need to find another way of looking this setting up.

CGFontDefaultAllowsFontSmoothing matches my prefs checkbox (but requires application restart to pick up changes).

bungeman@ how can we land this change? Internal Skia contribution docs are out of date and the page linked on the public site[1] is a 404.

[1] https://skia.org/dev/contrib/contrib/submit

From my playing around with different settings, it seems that Apple has replaced sub-pixel font smoothing levels (AppleFontSmoothing 1-3) from previous OS versions with grayscale font smoothing levels which add a bit to the font weight based on the level in order to mimic the same look that the sub-pixel levels provided.

Chrome and Electron-based apps don't use the same rendering as macOS native apps do and so that's why it seems that the macOS grayscale font smoothing levels have no effect on Chrome's rendering.

CGFontDefaultAllowsFontSmoothing will turn sub-pixel font smoothing back on, but apparently at a performance cost, so rather than forcing Chrome to use sub-pixel rendering, ideally we should figure out a way to render using macOS's various font weights that match the OS's rendering style.

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/6112f0b068b3101f42d53c53345a761a69a46c20

commit 6112f0b068b3101f42d53c53345a761a69a46c20
Author: Ben Wagner <bungeman@google.com>
Date: Thu Sep 27 21:54:03 2018

Detect macOS font smoothing behavior.

In macOS 14 the font smoothing behavior was changed. On macOS 13 and lower
requesting smoothing would either do nothing or apply fake bolding and
subpixel coverage, depending on a user setting. On macOS 14 this same user
setting causes smoothing to either do nothing or apply fake bolding. Skia
had been checking for subpixel coverage to know whether to ask for
smoothing, but since subpixel coverage is no longer provided Skia won't
ask for smoothing. However, some still want to see the fake bolding.

This changes behavior in Skia to detect if requesting smoothing does not
change the rendering, if it changes the rendering, or if it changes the
rendering and applies subpixel coverage. The code which conflated the
changing of rendering and subpixel coverage is updated to check for the
appropriate conditions.

This has the odd effect of making the setLCDRenderText setting in Skia on
macOS 14 not actually turn on subpixel coverage but instead apply
fake-bolding to closest match the behavior of the request on previous
versions of macOS.

Bug:  chromium:858861 
Change-Id: Ic7ff22e171a15be20e0bcccb10b0c4798cba8b72
Reviewed-on: https://skia-review.googlesource.com/157566
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>

[modify] https://crrev.com/6112f0b068b3101f42d53c53345a761a69a46c20/src/ports/SkFontHost_mac.cpp

+abdulsyed@: Is it (technically/organizationally) possible for us to cherry pick the above Skia change into M70?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/df58afe5a539b9adf5f2708ff71566e1c6cf6679

commit df58afe5a539b9adf5f2708ff71566e1c6cf6679
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Fri Sep 28 19:44:44 2018

Roll src/third_party/skia 656cefe65d62..f88f49d2a52e (11 commits)

https://skia.googlesource.com/skia.git/+log/656cefe65d62..f88f49d2a52e


git log 656cefe65d62..f88f49d2a52e --date=short --no-merges --format='%ad %ae %s'
2018-09-28 mtklein@google.com Revert "Have Renderer use combined path code"
2018-09-28 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/angle2 e8dd07969872..af0f31d3a909 (2 commits)
2018-09-27 csmartdalton@google.com Cleanup resource flags
2018-09-27 skia-autoroll@skia-public.iam.gserviceaccount.com Roll third_party/externals/angle2 122919bddd98..e8dd07969872 (4 commits)
2018-09-27 bungeman@google.com Detect macOS font smoothing behavior.
2018-09-27 egdaniel@google.com Remove assert about top left origin in lazy image generator unique key.
2018-09-27 herb@google.com Have Renderer use combined path code
2018-09-27 nathanrogers@google.com Fix a typo in SkISize comments
2018-09-27 bsalomon@google.com Reland "Change how GrTextureOp computes outset vertices."
2018-09-27 scroggo@google.com Make SkCodec truly default to sRGB
2018-09-27 borenet@google.com [infra] Add nightly UpdateGoDEPS


Created with:
  gclient setdep -r src/third_party/skia@f88f49d2a52e

The AutoRoll server is located here: https://autoroll.skia.org/r/skia-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux-chromeos-compile-dbg;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel

BUG= chromium:858861 ,chromium:887372
TBR=bsalomon@chromium.org

Change-Id: I4800ec89e6f922e57489b97b2672cf009c93dd34
Reviewed-on: https://chromium-review.googlesource.com/1250949
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#595184}
[modify] https://crrev.com/df58afe5a539b9adf5f2708ff71566e1c6cf6679/DEPS

This looks better with the change in c#28, but still notably worse than Safari. Are they doing something special?

 Issue 890714  has been merged into this issue.

Skia discussed what else could be done to fix this further, and it is challenging: It is unclear what Apple is doing. Gaining more understanding would certainly help. Note it is also somewhat debatable what is "better" and what Chrome should be doing here- mixed reviews across even some of the referenced forums/users. As far as the urgency of the bug goes, we hope we have resolved the core usability concern, propose lower priority tracking bug for better understanding of the differences and potential improvement in the future.

Testing the dev build with the above Skia change merged in, here are some comparison screenshots, all taken on a non-retina screen. I have AppleFontSmoothing set to 2 as the default of 3 is too heavy and causes smudging (especially apparent in Safari for non-retina).

The first shot is of this page. The chrome's font rendering is much better, but otherwise fonts appear quite light - drop down menus appear very light, as shown in the fourth shot. The second shot is with an extension to force --webkit-font-smoothing: antialiased on all pages. Finally the last shot is from Safari.

Subjectively I feel the second shot looks best; Safari's rendering appears to be way too heavy even with AppleFontSmoothing dialled down.

Deleted: Screen Shot 2018-10-09 at 12.05.58 PM.png 404 KB

	Screen Shot 2018-10-09 at 12.05.58 PM.png 404 KB View Download

Deleted: Screen Shot 2018-10-09 at 12.05.55 PM.png 407 KB

	Screen Shot 2018-10-09 at 12.05.55 PM.png 407 KB View Download

Deleted: Screen Shot 2018-10-09 at 12.05.51 PM.png 435 KB

	Screen Shot 2018-10-09 at 12.05.51 PM.png 435 KB View Download

Deleted: Screen Shot 2018-10-09 at 12.12.18 PM.png 51.7 KB

	Screen Shot 2018-10-09 at 12.12.18 PM.png 51.7 KB View Download

Closing per c#33