Open Bug 1625606 Opened 4 years ago Updated 5 months ago

Font smoothing on 2019 Macbook Pro 16" does not match Safari (looks more bold)

Categories

(Core :: Graphics: Text, defect, P3)

74 Branch
Unspecified
macOS
defect

Tracking

()

ASSIGNED

People

(Reporter: yoasif, Assigned: sam, NeedInfo)

References

(Blocks 1 open bug, )

Details

Attachments

(8 files)

Attached image firefox-mac.png

Initially reported https://www.reddit.com/r/firefox/comments/fq4myb/considering_switching_to_firefox_but_fonts_look/

Steps to reproduce:

  1. Navigate to https://www.reddit.com/r/firefox/comments/fq4myb/considering_switching_to_firefox_but_fonts_look/

What happens:

Text appears bolder than both Safari and Chrome on the same device.

User says this occurs everywhere, but can be seen in the post above - user has provided screenshots.

User is using default scaling settings on macOS and "Use font smoothing when available".

User sees the same issue on Nightly.

Attached image safari-mac.png
Attached image chrome-mac.png
Attached file about:support

:yoasif, if you think that's a regression, then could you try to find a regression range in using for example mozregression?

The reddit page mentioned has a webkit-specific rule -webkit-font-smoothing: antialiased on the <body> element, which affects the antialiasing used. (If you use the Safari inspector to disable that rule, you'll see the rendering become like Firefox.)

The equivalent rendering in Firefox can be achieved with -moz-osx-font-smoothing: grayscale, though in my testing it seems to be necessary to trigger a refresh of the display (e.g. by resizing the window) to see the effect after adding it in the Inspector.

Maybe we should try aliasing -webkit-font-smoothing: antialiased to the Gecko property? I thought we'd considered that in the past, but don't recall what we concluded, if anything.

(In reply to Jonathan Kew (:jfkthame) from comment #5)

Maybe we should try aliasing -webkit-font-smoothing: antialiased to the Gecko property? I thought we'd considered that in the past, but don't recall what we concluded, if anything.

Seems like a relatively low effort thing to do. I assume that there is no hope of standardizing a font-smoothing property since it's quite platform specific (though it does feel somewhat similar to shape-rendering?) and so that makes it more palatable to implement the -webkit alias.

Does Chrome on macOS also follow -webkit-font-smoothing?

(In reply to Cameron McCormack (:heycam) from comment #6)

(In reply to Jonathan Kew (:jfkthame) from comment #5)

Maybe we should try aliasing -webkit-font-smoothing: antialiased to the Gecko property? I thought we'd considered that in the past, but don't recall what we concluded, if anything.

Seems like a relatively low effort thing to do. I assume that there is no hope of standardizing a font-smoothing property since it's quite platform specific (though it does feel somewhat similar to shape-rendering?) and so that makes it more palatable to implement the -webkit alias.

I'm not sure. I can't recall offhand whether webkit/blink do something with this property on non-macOS platforms. There was some discussion of this on the old www-style mailing list back in 2012, but I'd need to go back and refresh my memory about the details. And of course things may have changed since then.

Does Chrome on macOS also follow -webkit-font-smoothing?

Yes.

Priority: -- → P3

Out of curiosity, I experimented with Chrome on both Windows and Linux, and AFAICS it doesn't change text rendering at all in response to -webkit-font-smoothing, although the devtools inspector exposes the property name & values.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Severity: normal → S3

FWIW, this also occurs on https://old.reddit.com which doesn't use -webkit-font-smoothing. Nightly is on the left, Safari is on the right.

This issue doesn't occur when the "Use font smoothing when available" option in System Preferences > General is disabled, but that option is no longer present in System Preferences in 10.15.

(In reply to Sam Johnson from comment #10)

This issue doesn't occur when the "Use font smoothing when available" option in System Preferences > General is disabled, but that option is no longer present in System Preferences in 10.15.

Here's another comparison to substantiate the claim above. This is with "Use font smoothing when available" disabled-- Nightly on left, Safari on right, and Nightly looks great.

Okay, so we seem to be having two issues here:

  1. On pages which use -webkit-font-smoothing: antialised but not -moz-osx-font-smoothing: grayscale (e.g. new Reddit), Safari and Chrome have lighter fonts than Firefox.
  2. On macOS 10.15+, pages which do not use either of those properties (e.g. Google Calendar, old Reddit) still have slightly lighter fonts in Safari and Chrome than in Firefox. (But not quite as light as with font smoothing turned off / -webkit-font-smoothing: antialised set.)

(And then there's the question of whether the slightly bolder look is preferable or not.)

I've filed bug 1670993 about case 1. Let's keep this bug about case 2.

Lee, have you seen this bug before? (Did we maybe even talk about it?) Chrome is showing the "lighter" look, so I suspect their Skia font code (preblending with a different gamma?) must have diverged from ours.

Flags: needinfo?(lsalzman)
See Also: → 1670993

(In reply to Markus Stange [:mstange] from comment #12)

Okay, so we seem to be having two issues here:

  1. On pages which use -webkit-font-smoothing: antialised but not -moz-osx-font-smoothing: grayscale (e.g. new Reddit), Safari and Chrome have lighter fonts than Firefox.
  2. On macOS 10.15+, pages which do not use either of those properties (e.g. Google Calendar, old Reddit) still have slightly lighter fonts in Safari and Chrome than in Firefox. (But not quite as light as with font smoothing turned off / -webkit-font-smoothing: antialised set.)

(And then there's the question of whether the slightly bolder look is preferable or not.)

I've filed bug 1670993 about case 1. Let's keep this bug about case 2.

Lee, have you seen this bug before? (Did we maybe even talk about it?) Chrome is showing the "lighter" look, so I suspect their Skia font code (preblending with a different gamma?) must have diverged from ours.

Skia uses a different solution for representing subpixel AA glyph masks than we do. We originally came up with the solution together of using a light-on-dark or dark-on-light mask depending on the color of the text, such that we have two different masks to match what we observed to be happening with native text rendering at the time. Chrome/Skia went in a different direction of just using a single mask regardless by altering the luminance of the text's color but just always querying the mask via black-text-on-white-background rendering.

It would be worth someone investigating whether we just want to kill off our specific solution and fall in with the Chrome approach, of if we still prefer to keep our specific workaround here.

Our solution: https://searchfox.org/mozilla-central/source/gfx/skia/skia/src/ports/SkFontHost_mac.cpp#2450
Skia's solution: https://searchfox.org/mozilla-central/source/gfx/skia/skia/src/ports/SkFontHost_mac.cpp#2465

Given that font smoothing is solidly in the retirement process on macOS, and to ease the future Skia updating burden, I would be open to just retiring our specific solution going forward in the next Skia update if we don't much mind the change in look in cases where users still have font-smoothing enabled.

Flags: needinfo?(lsalzman)
Attached image comparison

This still seems to be an issue on current Nightly. Here is a fairly straightforward reproduction:

data:text/html,<p style='color:gray'>Hello world!</p>

As you can see in the attached screenshot, with Nightly on the left and Safari on the right, there is a pretty big difference in rendering with default OS settings on a non-retina display.

Note that this seems to have something to do with text color. If you change the above example to use black, the issue goes away.

(In reply to Lee Salzman [:lsalzman] from comment #13)

(In reply to Markus Stange [:mstange] from comment #12)

Okay, so we seem to be having two issues here:

  1. On pages which use -webkit-font-smoothing: antialised but not -moz-osx-font-smoothing: grayscale (e.g. new Reddit), Safari and Chrome have lighter fonts than Firefox.
  2. On macOS 10.15+, pages which do not use either of those properties (e.g. Google Calendar, old Reddit) still have slightly lighter fonts in Safari and Chrome than in Firefox. (But not quite as light as with font smoothing turned off / -webkit-font-smoothing: antialised set.)

(And then there's the question of whether the slightly bolder look is preferable or not.)

I've filed bug 1670993 about case 1. Let's keep this bug about case 2.

Lee, have you seen this bug before? (Did we maybe even talk about it?) Chrome is showing the "lighter" look, so I suspect their Skia font code (preblending with a different gamma?) must have diverged from ours.

Skia uses a different solution for representing subpixel AA glyph masks than we do. We originally came up with the solution together of using a light-on-dark or dark-on-light mask depending on the color of the text, such that we have two different masks to match what we observed to be happening with native text rendering at the time. Chrome/Skia went in a different direction of just using a single mask regardless by altering the luminance of the text's color but just always querying the mask via black-text-on-white-background rendering.

It would be worth someone investigating whether we just want to kill off our specific solution and fall in with the Chrome approach, of if we still prefer to keep our specific workaround here.

Our solution: https://searchfox.org/mozilla-central/source/gfx/skia/skia/src/ports/SkFontHost_mac.cpp#2450
Skia's solution: https://searchfox.org/mozilla-central/source/gfx/skia/skia/src/ports/SkFontHost_mac.cpp#2465

Given that font smoothing is solidly in the retirement process on macOS, and to ease the future Skia updating burden, I would be open to just retiring our specific solution going forward in the next Skia update if we don't much mind the change in look in cases where users still have font-smoothing enabled.

I believe this issue lies within WR rather than Skia. The following patch fixes the text rendering on my machine to appear consistent with other apps.

diff --git a/gfx/wr/wr_glyph_rasterizer/src/platform/macos/font.rs b/gfx/wr/wr_glyph_rasterizer/src/platform/macos/font.rs
--- a/gfx/wr/wr_glyph_rasterizer/src/platform/macos/font.rs
+++ b/gfx/wr/wr_glyph_rasterizer/src/platform/macos/font.rs
@@ -737,9 +737,9 @@ impl FontContext {
                 // We explicitly do not do this for grayscale AA ("Alpha without
                 // smoothing" or Mono) because those rendering modes are not
                 // gamma-aware in CoreGraphics.
-                self.gamma_lut.coregraphics_convert_to_linear(
-                    &mut rasterized_pixels,
-                );
+                //self.gamma_lut.coregraphics_convert_to_linear(
+                //    &mut rasterized_pixels,
+                //);
             }
 
             for pixel in rasterized_pixels.chunks_mut(4) {
@@ -765,11 +765,11 @@ impl FontContext {
                 // some "preblending" based on the text color.
                 // In Alpha + smoothing mode, this will also convert subpixel AA
                 // into grayscale AA.
-                self.gamma_correct_pixels(
-                    &mut rasterized_pixels,
-                    font.render_mode,
-                    font.color,
-                );
+                //self.gamma_correct_pixels(
+                //    &mut rasterized_pixels,
+                //    font.render_mode,
+                //    font.color,
+                //);
             }
         }

Note that macOS no longer has subpixel AA, so I believe this code is no longer needed.

Until macOS 10.14, "font smoothing" meant sub-pixel antialiasing of text. However, since macOS 10.14, sub-pixel antialiasing is no longer supported. Gamma correction is necessary for sub-pixel font smoothing, but it produces undesirable effects with grayscale font smoothing.

Firefox does not support any macOS versions with sub-pixel font smoothing, so the gamma correction code has been removed. This improves font rendering, especially on non-retina displays, to match other applications and browsers.

Assignee: nobody → sam
Status: NEW → ASSIGNED
Flags: needinfo?(jmuizelaar)
Attachment #9363847 - Attachment description: Bug 1625606 - Remove gamma correction from macOS font smoothing r?#gfx-reviewers → Bug 1625606 - Adjust macOS font smoothing gamma by luminance r?#gfx-reviewers
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: