1743273 - 'gfx.font_rendering.cleartype_params.rendering_mode' sometimes does not work

Status: RESOLVED FIXED

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

Description

[tranquilknight]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Safari/537.36 Edg/96.0.1054.34

Steps to reproduce:

After launching Firefox in various scenarios, 'gfx.font_rendering.cleartype_params.rendering_mode' does not have any effect.

Various scenarios: Launching normally, troubleshoot mode, refresh Firefox, new installation on a new Windows user profile.

Actual results:

I prefer to use 'gfx.font_rendering.cleartype_params.rendering_mode=5'. At first launch, this option does not affect font rendering. Fonts look like they are rendering with the default value of '-1'.

about:config shows the value '5' but rendered font look like the affecting value is '-1'. To get the desired fonts, I need to revert the value to the default and, change it back to 5.

As soon as the value changes to 5, everything becomes normal. But it stops working randomly after opening a link in a new tab. Sometimes it starts working after a refresh, sometimes it needs to be changed manually to work again.

I'm not quite sure, but this has been happening since 91 (I think).

Expected results:

At launch, fonts should be rendered with whatever the set value of 'gfx.font_rendering.cleartype_params.rendering_mode' is, instead of its default -1.

Also, after changing its value manually, it shouldn't stop affecting fonts after opening a new tab or refreshing the page.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Andrew Osmond [:aosmond] (he/him)]

We call gfxDWriteFont::UpdateClearTypeVars during startup, and whenever the prefs change, so it should get applied at launch. However we only apply the gfx.font_rendering.cleartype_params.rendering_mode pref setting if gfxVars::SystemTextQuality is CLEARTYPE_QUALITY:

https://searchfox.org/mozilla-central/rev/4c184ca81b28f1ccffbfd08f465709b95bcb4aa1/gfx/thebes/gfxDWriteFonts.cpp#225

gfxVar::SystemTextQuality value is controlled by:

https://searchfox.org/mozilla-central/rev/4c184ca81b28f1ccffbfd08f465709b95bcb4aa1/gfx/thebes/gfxDWriteFonts.cpp#51

which suggests it can change dynamically. We seem to monitor for this here:

https://searchfox.org/mozilla-central/rev/4c184ca81b28f1ccffbfd08f465709b95bcb4aa1/widget/windows/nsWindow.cpp#5167
https://searchfox.org/mozilla-central/rev/4c184ca81b28f1ccffbfd08f465709b95bcb4aa1/widget/windows/nsWindow.cpp#5360

The fact that the pref toggle is necessary to activate the font mode change then suggests that we got neither of these events.

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

Maybe we should be listening on changes to SPI_SETCLEARTYPE too although it seems like it is more of a newer convenience parameter and you would think it would still trigger SPI_SETFONTSMOOTHINGTYPE notifications.

We used to update on every WM_PAINT message, but that was changed in bug 1479640 because it was showing up in profiles.

Comment 4

[Lee Salzman [:lsalzman]]

Bob, it looks like you added this behavior in bug 1698946. Can you take a look?

Comment 5

[Lee Salzman [:lsalzman]]

tranquilknight, can you paste your "about:support" information?

It looks suspicious roundabout here: https://searchfox.org/mozilla-central/source/gfx/ipc/GPUParent.cpp#263
Like under some circumstances we might not call DWriteSettings::Initialize(), whereby gfxDWriteFont::InitDWriteSupport() is only hit on some paths to call that... I would think we always want to ensure that Initialize() (or maybe just InitDWriteSupport()) gets called for the WR path regardless of what happens?

Comment 6

[Lee Salzman [:lsalzman]]

Actually, n'm. It should be okay that we don't initialize DWriteSettings in the parent process actually, since all those settings theoretically are getting sent over from the content process... The problem must lie elsewhere.

On the flip side, I don't see where InitDWriteSupport() ever gets called in the content processes?
Looks like here: https://searchfox.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp#403
But the check for Skia seems sketchy given how we actually work these days (it's the only actual content backend we support).

Comment 7

[tranquilknight]

Attachment: Firefox_about_support.txt

@lsalzman I have attached a text file containing the about:support information. I apologise if this isn't the preferred way. Tried Pastebin, but it is stuck on moderation queue.

Comment 8

[Lee Salzman [:lsalzman]]

That's fine, thanks! Just wanted to verify if this was a normal-looking Windows/D3D11 setup, which it seems.

Comment 9

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

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

Comment 10

[Bob Owen (:bobowen)]

I'll take a look.

Comment 11

[Bob Owen (:bobowen)]

Finally found time to track down the problem and I think I've found it.
Basically we don't hit this line on start up in the content processes:
https://searchfox.org/mozilla-central/rev/682e5a82d403974bacb779c1db515962d946be48/gfx/thebes/gfxDWriteFonts.cpp#150

But we do when the actual pref is changed.
Should have a fix early next week.

Comment 12

[Lee Salzman [:lsalzman]]

Nice catch, Bob!

Comment 13

[Bob Owen (:bobowen)]

Attachment: Bug 1743273: Ensure gfxDWriteFont::sForceGDIClassicEnabled is set on initialization. r=lsalzman!

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2e3add91ac7a
Ensure gfxDWriteFont::sForceGDIClassicEnabled is set on initialization. r=lsalzman

Comment 15

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/2e3add91ac7a

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta approval when you get a chance.

Comment 17

[Bob Owen (:bobowen)]

Comment on attachment 9258362 [details]
Bug 1743273: Ensure gfxDWriteFont::sForceGDIClassicEnabled is set on initialization. r=lsalzman!

Beta/Release Uplift Approval Request

• User impact if declined: Clear type rendering mode pref changes will continue to not take effect on start up.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: * set pref gfx.font_rendering.cleartype_params.rendering_mode = 5
• restart the browser
• navigate to https://en.wikipedia.org/wiki/Alan_Turing
• change pref back to -1

After this fix the final step should cause a noticeable change in the text rendering.
Before the fix it doesn't because the pref setting of 5 doesn't have the desired effect on start-up.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple change, the effect of which is to set a static variable in non-parent processes at start-up as well as when the pref is changed.
• String changes made/needed: None

Comment 18

[Donal Meehan [:dmeehan]]

Comment on attachment 9258362 [details]
Bug 1743273: Ensure gfxDWriteFont::sForceGDIClassicEnabled is set on initialization. r=lsalzman!

Approved for 97.0b3. Thanks.

Comment 19

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/ef693cfca9f7

Comment 20

[Ciprian Georgiu, Desktop QA]

Hi, Bob! It seems that I have the same expected results on a fixed build, Beta 97.0b3 as well as on an affected Nightly 96.0a1 (20211127220034). I can't see any changes to the text rendering when switching the pref gfx.font_rendering.cleartype_params.rendering_mode from 5 to -1, on Win 10 x64. I've followed you steps from comment 17. Can you please help with this, maybe I'm missing something?

Comment 21

[Bob Owen (:bobowen)]

(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #20)

Hi, Bob! It seems that I have the same expected results on a fixed build, Beta 97.0b3 as well as on an affected Nightly 96.0a1 (20211127220034). I can't see any changes to the text rendering when switching the pref gfx.font_rendering.cleartype_params.rendering_mode from 5 to -1, on Win 10 x64. I've followed you steps from comment 17. Can you please help with this, maybe I'm missing something?

Ah I guess it might depend on your system cleartype settings.
Do you see a change in text rendering when you change the pref from -1 to 5?
(I find it helps if I have about:config in a separate window so I can see the other web page as I change it.)

By the way I have just tested Fx97.0b3 and the fix seems to be working.
I can reproduce the issue in release.

Comment 22

[Ciprian Georgiu, Desktop QA]

(In reply to Bob Owen (:bobowen) from comment #21)

Ah I guess it might depend on your system cleartype settings.
Do you see a change in text rendering when you change the pref from -1 to 5?
(I find it helps if I have about:config in a separate window so I can see the other web page as I change it.)

Yes, this is how I previously tested, but I can only see the transition effect on the fonts, when changing the value of the prefs. It looks the same on both builds, affected and latest Beta 97. I also changed a bit the clear type settings in Win 10, I didn't make any difference, it appears.

By the way I have just tested Fx97.0b3 and the fix seems to be working.
I can reproduce the issue in release.

Thanks! I think we can mark this as verified, per your checking on Beta 97.