1803154 - Fonts look thicker after bug 1801512

Status: VERIFIED FIXED

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

Description

[Itiel]

Environment:
Windows 10, DPI 150%, ClearType enabled, FontSmoothingGamma in HKEY_CURRENT_USER\Control Panel\Desktop is set to 1200

After bug 1801512, fonts (across Firefox UI also) look thicker.
See some screenshots for before & after, also when compared to Chrome and Notepad

Comment 1

[Itiel]

Attachment: Latest Nightly

Comment 2

[Itiel]

Attachment: Pre bug 1801512

Comment 3

[Itiel]

Attachment: How it looks on Chrome

Comment 4

[Itiel]

Attachment: Comparison with notepad with the same font, current Nightly

Comment 5

[Itiel]

Attachment: Comparison with notepad with the same font, pre bug 1801512

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

:jfkthame, since you are the author of the regressor, bug 1801512, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1801512

Comment 8

[chaotic_sys]

I assume that Firefox displays fonts correctly and according to the settings. Another thing is that others don't do that.

Try to see how Microsoft Edge renders these pages - with edge://flags/#edge-enhance-text-contrast enabled. (Description: "Renders text using the same contrast and gamma settings that are used elsewhere in Windows. Run the ClearType Text Tuner to adjust the contrast and gamma settings for your monitor. – Windows")

You can also set the EnhancedContrastLevel value in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DISPLAY1 to zero in the registry. And in Firefox you will get a view approximately like in the system.

Comment 9

[Jonathan Kew [:jfkthame]]

I'm not really sure what's the right thing to do here.

I can confirm that when I use the ClearType Tuner to adjust text rendering on my system, it never seems to touch the GammaLevel values under the HKCU\SOFTWARE\Microsoft\Avalon.Graphics\DISPLAYn paths, but does change the Control Panel\Desktop value for FontSmoothingGamma. So to respect the CTTuner's settings, it seems like we'd have to use the Control Panel\Desktop value.

Yet the CTTuner does modify other values under Avalon.Graphics\DISPLAY, so it seems weird that we'd be expected to read some parameters from each of these quite different locations.

A further complication is that ClearType settings are actually per-display, not global (so on my dual-display system, I have both Avalon.Graphics\DISPLAY1 and AvalonGraphics\DISPLAY2 registry paths, with different settings recorded in each). But in Firefox we don't appear to handle this; we just get the default parameters from DWriteFactory::CreateRenderingParams, which (according to MSDN) returns the values for the primary display. So they're liable to be wrong for any other displays.

(We have code in gfxWindowPlatform to read the per-monitor settings using DWriteFactory::CreateMonitorRenderingParams, but as far as I can see these are just reported in about:support as "ClearType Parameters", but not used for rendering.)

And how does all this work in relation to the single Control Panel\Desktop\FontSmoothingGamma value, which does not seem to have separate per-display values?

Lee, any ideas here?

Comment 10

[Lee Salzman [:lsalzman]]

(In reply to Jonathan Kew [:jfkthame] from comment #9)

I'm not really sure what's the right thing to do here.

I can confirm that when I use the ClearType Tuner to adjust text rendering on my system, it never seems to touch the GammaLevel values under the HKCU\SOFTWARE\Microsoft\Avalon.Graphics\DISPLAYn paths, but does change the Control Panel\Desktop value for FontSmoothingGamma. So to respect the CTTuner's settings, it seems like we'd have to use the Control Panel\Desktop value.

Yet the CTTuner does modify other values under Avalon.Graphics\DISPLAY, so it seems weird that we'd be expected to read some parameters from each of these quite different locations.

A further complication is that ClearType settings are actually per-display, not global (so on my dual-display system, I have both Avalon.Graphics\DISPLAY1 and AvalonGraphics\DISPLAY2 registry paths, with different settings recorded in each). But in Firefox we don't appear to handle this; we just get the default parameters from DWriteFactory::CreateRenderingParams, which (according to MSDN) returns the values for the primary display. So they're liable to be wrong for any other displays.

(We have code in gfxWindowPlatform to read the per-monitor settings using DWriteFactory::CreateMonitorRenderingParams, but as far as I can see these are just reported in about:support as "ClearType Parameters", but not used for rendering.)

And how does all this work in relation to the single Control Panel\Desktop\FontSmoothingGamma value, which does not seem to have separate per-display values?

Lee, any ideas here?

So long as we could determine which monitor we're actually on, it sounds like those are the parameters we want to be using?

Otherwise, as far as ClearType Tuner, your guesses are as good mine...

Comment 11

[chaotic_sys]

Seems like nothing needs to be changed : )

Just my thoughts. At first there was only setting - Control Panel\Desktop > FontSmoothingGamma.

"... One question you might ask is why we don't just ask the display what its gamma characteristics are. [...] First, many older displays do not provide gamma correction or if they do, it is sometimes incorrect. With new EDID information from displays becoming available, we should be able to get accurate gamma information as well as subpixel orientation." https://web.archive.org/web/20110917034410/http://blogs.msdn.com/b/fontblog/archive/2005/10/20/483557.aspx

Now this setting (step 2 of 5) is left for GDI rendering only. A new version of ClearType takes settings only from Avalon.Graphics. And, as I understand it, now the gamma value, indeed, is taken from each display if possible - and should not be adjusted by user in any way. A user is given other settings - Enhanced Contrast, for example.
https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/cleartype-registry-settings
https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/cleartype-overview

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1801512

Comment 13

[Hashim]

As someone also on Windows 10 who recently had this "fix" pushed after upgrading to Firefox 109.0, I too have ended up here because of how uncomfortable the new bolder typefaces are to read. Not only this, but as a web developer who does most of his development in Firefox, and comparing my sites side-by-side in Firefox and Chrome, it points to more stylistic inconsistency between the two than ever, meaning that thanks to this change my users are essentially experiencing two different versions of all the sites I design. This is the kind of browser inconsistency web developers have spent years trying to get away from. Please consider reverting this - it might technically be a "fix", but I would question what exactly it is fixing when it results in unexpected, ugly behaviour that is inconsistent with how other browsers look and makes for a worse UX for most users. A Reddit comment with instructions on reverting the changes fixes for power users has gathered 80 upvotes since Firefox 109.0 was released 2 days ago.

Comment 14

[aegura]

You fixed what was not broken and now it's broken. This fix should definitely be reverted - or reworked and thoroughly tested with various ClearType settings.

You're killing Firefox, brothers. Seriously, non-advanced users won't read these how-tos on Reddit and dig into about:config - they'll just uninstall Firefox :(

Firefox displays fonts correctly and according to the settings. Another thing is that others don't do that.

This is not true. We can see what "correctly displayed fonts" are in Windows system apps like Notepad or Wordpad, which obviously respect ClearType settings exactly as intended by the creators of ClearType. Fonts in Notepad (with the same font-family, font-size and font-weight) are far from the same as in Firefox. Before this "fix", they were nearly the same.

Comment 15

[aegura]

Attachment: WordPad vs Firefox

Comment 16

[hujq]

On my Windows 11 22H2 system, without using ClearType Text Tuner, HKEY_CURRENT_USER\Control Panel\Desktop\FontSmoothingGamma is 1200 and HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics\DISPLAY*\GammaLevel is 2200.

By changing the two values, I can see that Edge browser, UWP apps like Calculator and Settings, and the toolbar/menubar of Explorer or Notepad, all follow HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics\DISPLAY*\GammaLevel and ignore HKEY_CURRENT_USER\Control Panel\Desktop\FontSmoothingGamma, and 2200 looks much better than 1200 which is too dark. The content areas of Explorer and Notepad, as well as other legacy apps such as Regedit, are affected by neither of the two values. And I haven't found anything that uses HKEY_CURRENT_USER\Control Panel\Desktop\FontSmoothingGamma which, strangely, is indeed set by step 2 of ClearType Text Tuner.

Firefox could probably just use HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics\DISPLAY*\GammaLevel.

Comment 17

[dan]

Attachment: Comparison with ClearType OFF

Please see the attached screenshots comparing the visible changes to font rendering in Firefox 108 vs 109 (Windows 10 v22H2). There is also a shot of Edge v109, which displays fonts very similar to Firefox 108.

The Firefox 109 fonts are definitely an unwanted step-back in clarity and readability.

I have ClearType turned OFF.

Adjusting the gfx.font_rendering.cleartype_params.gamma value has no effect.

Comment 18

[Jonathan Kew [:jfkthame]]

While the change in bug 1801512 appeared to improve rendering for some cases/some users, it's clear from the reports we're seeing that it also made things significantly worse for others. On balance, it looks like it may have resulted in more problems than improvements. As such, I propose to revert that change for the time being, which should restore the rendering to how it was in earlier versions.

Thanks to all who have reported the issues here, with details of local machine settings and the results they're seeing. The entire situation is still somewhat confusing, with multiple sometimes-conflicting registry values involved, and with inconsistency between even Microsoft's own applications, so this is unlikely to be the end of the story, but for now we'll return to how things were prior to the attempt to fix bug 1801512.

Comment 19

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1803154 - Back out changeset c1b0ce76a51b (bug 1801512) because it seems to have made things worse for a number of users. r=lsalzman

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9b6e69ab8017
Back out changeset c1b0ce76a51b (bug 1801512) because it seems to have made things worse for a number of users. r=lsalzman

Comment 21

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox110 (beta). However, the bug still has low priority and has low severity.

:bhood, could you please increase the priority and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Comment 22

[Jonathan Kew [:jfkthame]]

[Tracking Requested - why for this release]:
The change we made to try and improve DirectWrite font rendering quality on Windows seems to have made things look worse for more users than it helped. It's a purely "cosmetic" change that doesn't affect functionality or compatibility of any features, so reverting to the previous rendering options shouldn't introduce any new regression risk.

Comment 23

[Jonathan Kew [:jfkthame]]

Comment on attachment 9313686 [details]
Bug 1803154 - Back out changeset c1b0ce76a51b (bug 1801512) because it seems to have made things worse for a number of users. r=lsalzman

Beta/Release Uplift Approval Request

• User impact if declined: A number of Windows users are seeing poorer font rendering, making them unhappy with Firefox and potentially motivating a switch to a different browser
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple backout to restore our previous behavior.
• String changes made/needed:
• Is Android affected?: No

Comment 24

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/9b6e69ab8017

Comment 25

[Pascal Chevrel:pascalc]

Comment on attachment 9313686 [details]
Bug 1803154 - Back out changeset c1b0ce76a51b (bug 1801512) because it seems to have made things worse for a number of users. r=lsalzman

Approved for 110 beta 5, thanks.

Comment 26

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/1dc7fc9e7fc4

Comment 27

[Rares Doghi, Desktop QA]

I will mark this issue Verified as fixed in both Nightly as well as Beta 110.0b5 by reproducing the initial Bug 1801512, Firefox will no longer consider the FontSmoothingGamma settings only the values from HKCU\SOFTWARE\Microsoft\Avalon.Graphics\DISPLAY1 GammaLevel.

Comment 28

[Alexandru Ionescu (needinfo me) [:alexandrui]]

(In reply to Pascal Chevrel:pascalc from comment #25)

Comment on attachment 9313686 [details]
Bug 1803154 - Back out changeset c1b0ce76a51b (bug 1801512) because it seems to have made things worse for a number of users. r=lsalzman

Approved for 110 beta 5, thanks.

== Change summary for alert #36789 (as of Wed, 25 Jan 2023 13:55:51 GMT) ==

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)	Performance Profiles
5%	google-docs ContentfulSpeedIndex	windows10-64-shippable-qr	fission warm webrender	1,012.96 -> 1,062.50	Before/After
4%	google-docs ContentfulSpeedIndex	windows10-64-shippable-qr	cold fission webrender	1,213.00 -> 1,262.67	Before/After

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)	Performance Profiles
4%	facebook ContentfulSpeedIndex	windows10-64-shippable-qr	cold fission webrender	902.50 -> 870.67

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=36789

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9313686 [details]
Bug 1803154 - Back out changeset c1b0ce76a51b (bug 1801512) because it seems to have made things worse for a number of users. r=lsalzman

Approved for 109.0.1

Comment 30

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/9c23db8cdb2d

Comment 31

[Rares Doghi, Desktop QA]

This issue is Verified as fixed in Release 109.0.1 (64-bit).

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Added to the 109.0.1 relnotes:

Reverted changes to Windows font smoothing which caused poor rendering on some configurations

Comment 33

[Alex Finder|PTO, back on Nov 25th]

(In reply to Pulsebot from comment #20)

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9b6e69ab8017
Back out changeset c1b0ce76a51b (bug 1801512) because it seems to have made
things worse for a number of users. r=lsalzman

== Change summary for alert #36810 (as of Fri, 27 Jan 2023 19:15:29 GMT) ==

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)	Performance Profiles
4%	google-docs ContentfulSpeedIndex	windows10-64-shippable-qr	fission warm webrender	996.61 -> 1,039.33	Before/After
4%	google-docs ContentfulSpeedIndex	windows10-64-shippable-qr	cold fission webrender	1,202.75 -> 1,248.67	Before/After

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=36810

Comment 34

[Jonathan Kew [:jfkthame]]

This is expected; it's just reverting improvements that were noted in bug 1801512 comment 24.