Text for tab titles, library menu, hamburger menu, new tab page etc. have become sharper on Windows.

Example image taken with Basic compositor.

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e9e463c46a688e1d97e7ca8fbf8ced1498cb11fe&tochange=f03d8ccb0864e36d3a106a38db23b94fb9c8a174

Regressed by Bug 1553818.

Additional confirmation here: https://www.reddit.com/r/firefox/comments/czidkf/noticeably_worse_font_rendering_in_tab_titles/eyz1xiz/

So, I ran mozregression a few times until the end to narrow the problem down completely to this commit which seems indeed to be relevant to the problem I'm facing:

Bug 1553818 - use GDI ClearType contrast for GDI font gamma. r=jrmuizel

If you look at bug 1553818, fonts were only artificially bold under some circumstances because of a bug, and the result you were previously accustomed to seeing was in fact just the entirely wrong result that should not have been there in the first place. The gamma is actually correct now which causes things to look less bold in some circumstances.

It sounds like there's still something wrong going on "ever since the latest version the font used for tab titles seems to present some artifacts that weren't there before. Plus when hovering over the tab titles, the letters in the titles start slightly flickering. "

https://www.reddit.com/r/firefox/comments/czidkf/noticeably_worse_font_rendering_in_tab_titles/

I looked at the anti-aliasing under a microscope, and the colors I am seeing on my own machine are consistent both before and after, with what the user attached in the bug report. They represent the pattern I would expect to see. The before image has the incorrect gamma (i.e. gamma that does not correspond to how Direct2D renders the text with the same color, font, and rendering parameters), and the after image has the correct gamma which corresponds to Direct2D. So, really, we've all been staring at the wrong result so long it feels normalized. We may need UI people to come and evaluate whether they need to change the font weight to compensate in some way, as they might have co-evolved the UI appearance based on this incorrect result...

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

I looked at the anti-aliasing under a microscope, and the colors I am seeing on my own machine are consistent both before and after, with what the user attached in the bug report. They represent the pattern I would expect to see. The before image has the incorrect gamma (i.e. gamma that does not correspond to how Direct2D renders the text with the same color, font, and rendering parameters), and the after image has the correct gamma which corresponds to Direct2D. So, really, we've all been staring at the wrong result so long it feels normalized. We may need UI people to come and evaluate whether they need to change the font weight to compensate in some way, as they might have co-evolved the UI appearance based on this incorrect result...

Hi, I'm the OP of the reddit thread linked above. Is there a chance that the font rendering on the tab titles varies from system to system? The way you're describing it, it definitely sounds like it's working as intended on your machine (I do understand that compared to Firefox builds earlier than July 25, text in menus and other areas was rendered bold whilst it shouldn't have). However in my experience besides the font not being rendered bold anymore, it also feels like it's just not quite as readable because of the annoying artifacts on the font. The very first pic linked above showing the before and after also feels different to how I see the font being rendered, although I could be wrong since I haven't zoomed in (I however can't show any examples right now because I'm typing from my phone. I'll make sure to add something to this thread tomorrow).

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

. . . So, really, we've all been staring at the wrong result so long it feels normalized. We may need UI people to come and evaluate whether they need to change the font weight to compensate in some way, as they might have co-evolved the UI appearance based on this incorrect result...

Mark, might you or someone else on the UI team take a look here? It sounds like we want to make a change here from this regression from 69 and the graphics team needs UI's input. I am not sure of the right person to ask so maybe you can help determine that.

We could still potentially take a patch in 70 beta but 71 might be a more realistic goal.

Changing the priority to p1 as the bug is tracked by a release manager for the current beta.
See What Do You Triage for more information

Tim, is there someone on the UI team who can look at this issue?

(In reply to Liz Henry (:lizzard) from comment #6)

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

. . . So, really, we've all been staring at the wrong result so long it feels normalized. We may need UI people to come and evaluate whether they need to change the font weight to compensate in some way, as they might have co-evolved the UI appearance based on this incorrect result...

Mark, might you or someone else on the UI team take a look here? It sounds like we want to make a change here from this regression from 69 and the graphics team needs UI's input. I am not sure of the right person to ask so maybe you can help determine that.

We could still potentially take a patch in 70 beta but 71 might be a more realistic goal.

I'll look into this.

Stephen, any news on this for 71 (we are at beta 7 of 12)? Thanks.

Fix-optional and untracking for 71 as there was no progress on this bug and we are nearing the end of the beta cycle.

Following up on Slack/email.

After discussion with shorlander it sounds like UX folks don't think there is a problem.

(In reply to Liz Henry (:lizzard) from comment #13)

After discussion with shorlander it sounds like UX folks don't think there is a problem.

I think the bug title accurately describes the situation. Text in the main UI (tab titles, bookmarks bar, etc.) is certainly sharper. This causes labels to appear slightly lighter than before.

While this could be considered a regression from our previous behavior, it is more consistent with how text is rendered throughout Windows.

Outside of altering how we render default weight text there isn't a simple stylistic change that I would recommend to address this. A possible solution would be increasing the overall size of the text, but that's a change that has other repercussions and is probably outside of the scope of this bug.

One caveat: I tested this on a range of devices and different displays (regular and high DPI). It's possible that different combinations of hardware and settings makes this difference in rendering more pronounced.