1910407 - Font rendering is too thick when window is wide wiggles when window is rescaled slowly.

Status: NEW

(Core :: Graphics: WebRender, defect, P2)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Resizing Window with Wiggling Fonts.

Build 20240729094831, on this page, if my window is the full width of my screen the rendering is thick. Then if I narrow my window, the font wiggles until I get to about 2/3rds width, at which point it snaps thin and stays thin. See attachments.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Thin (good) rendering

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Thick (bad) rendering

This bad rendering is the full window width.

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: about-support.txt

Comment 4

[Matthew Gaudet (he/him) [:mgaudet]]

Hrm. Ok, this seems to be not a regression; Using mozregression I launched all the way back to Firefox 116 and could reproduce; yet somehow I've never noticed this before?

Safari and Chrome do not reproduce

I do have scaling enabled on this monitor; it's a Dell P2715 with native resolution of 3840x2160, but I'm running with a scaled resolution of 2560x1440.

I'd swear I'd never noticed this before, laying the finger on GitHub, but I 1) can't say for sure -- I don't look at GitHub diffs that much 2) I did change my scaling in the last two months or so.

Comment 5

[Jonathan Kew [:jfkthame]]

It looks like the "bad" rendering occurs when things -- particularly the glyphs -- are suddenly not being aligned to the pixel grid but rendered at "random" unaligned positions. My guess is that this starts happening when the window (or something within it, such as the main document canvas) exceeds a threshold (4K device pixels, maybe) that causes us to start using a different code-path at some stage when painting.

More of a Graphics issue than a Layout one, I suspect. Not sure if it belongs in Webrender or somewhere else in the stack... also, not just a Text issue; if you watch the video (attachment 9416594 [details]) carefully, you can see that the borders around elements are also affected.

(I was going to ask if this was a regression, but mid-aired with your comment noting that it has been around for some time. It's a bit tricky for me to reproduce here, as I don't have such a wide screen, though I was able to reproduce with a window placed partially off-screen to the left, so that I can enlarge it to be significantly wider than the actual screen.)

Comment 6

[Bob Hood [:bhood]]

Matthew, since you are experiencing this in Nightly, can you please:

1. Open about:config and check to see if gfx.canvas.accelerated is enabled;
2. If so, please disable it and restart Firefox;
3. Test again and report the results here?

We have disabled Direct2D in Nightly in favor of Accelerated Canvas2D, so I would like to discount (or confirm) that as a cause.

Comment 7

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

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

Comment 8

[Jonathan Kew [:jfkthame]]

I don't see how this can be related to bug 1910138: in comment 4, Matthew says he reproduced this "all the way back to Firefox 116". Moreover, according to the about:support data in comment 3, he's on macOS, so Direct2D was never involved.

-> clearing the status flags from comment 7.

Comment 9

[Bob Hood [:bhood]]

about:support says he's using Nightly, so I want to be sure it's not AC2D. When I get confirmation from Matthew that disabling that doesn't fix the issue, I'll remove it from 1910138. (Just being cautious.)

Comment 10

[Matthew Gaudet (he/him) [:mgaudet]]

Yep. Behaviour is the same with gfx.canvas.accelerated=false on 20240802091953

Comment 11

[Bob Hood [:bhood]]

Thanks for taking the time to check, Matthew. We can probably discount 1910138 as being involved here.

Kicking to WR so Glenn can eval.

Comment 12

[Glenn Watson [:gw]]

Severity setting looks OK as an S3. Note to self: first step to investigate this would probably be to compare the display lists being sent by Gecko on a couple of these frames, and see if there are small differences from layout coming in glyph positions and/or spatial node transforms. That will tell us where to look further for the root cause of the bug.

Comment 13

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: ReproducingSingleFile.html

Just in case GitHub deploys new CSS or somesuch that breaks this, I'm attaching a SingleFile copy of the page, and I have confirmed the SingleFile continues to reproduce.