1726431 - Rendering of extremely tall content becomes erratic after 16M device pixels height

Status: NEW

(Core :: Graphics, defect, P3)

Description

[Jonathan Kew [:jfkthame]]

Attachment: Testcase with extremely tall content

View the attached testcase on a non-hidpi screen.

The main test element here is just over 16M pixels tall. Scroll to the very bottom, and observe the erratic rendering of the last line -- glyphs are shifted up/down from the proper baseline, and the glyph bitmaps may be broken (e.g. stretched or squashed by a pixel).

The effect also occurs on a Retina screen, though it is a bit less obvious; but there it begins half-way down the document, implying that the critical height is 16M device pixels, not CSS px. (Similarly, on a Windows display with 150% scaling, the corruption begins about 2/3 of the way down the document.)

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: Screenshot of the testcase (captured with Preview.app; the Firefox screenshot operation does not reproduce the bad rendering)

Comment 2

[Jonathan Kew [:jfkthame]]

Mozregression points to https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=02b89c29412b6c1444fe32a4847e5261e2bb3d00&tochange=2ccc6648064315964dd23039ad28ebf7d9f82999 as when this started happening.

Of the patches in that range, I wonder if Bug 1545006 - Use external scroll offsets to move primitives and clips into local space might be the issue?

Comment 3

[Jim Mathies [:jimm]]

Really interesting test case. I can reproduce on windows.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Glenn do you have an idea why this might happen?

Comment 5

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

Seems like a dupe of bug 1667534 and bug 1629859.

Comment 6

[Brad Werth [:bradwerth]]

I got a different, later regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a35461d1fc07e6e855d064453363a46d32bb5a3d&tochange=bd7c35b7e234712f94f6dbb755ad983c1db8b07b. I'm not able to spot an obvious candidate regressor.

Comment 7

[Darkspirit]

Can't repro when setting layers.async-pan-zoom.enabled:false!

Comment 8

[Glenn Watson [:gw]]

Does this occur on non-Windows platforms and/or with gfx.webrender.compositor disabled (restart required)?

Comment 9

[Darkspirit]

(In reply to Glenn Watson [:gw] from comment #8)

Does this occur on non-Windows platforms and/or with gfx.webrender.compositor disabled (restart required)?

Yes.
Gnome Wayland, Debian Testing, Intel Iris Graphics 6100 (BDW GT3), 2560x1440
STR: Zoom to 500% and press End to scroll to the bottom.

Reproducible with:
mozregression --launch 2021-08-28 --pref gfx.webrender.software:true -a https://bugzilla.mozilla.org/attachment.cgi?id=9236904
mozregression --launch 2021-08-28 --pref gfx.webrender.all:true -a https://bugzilla.mozilla.org/attachment.cgi?id=9236904
MOZ_X11_EGL=1 mozregression --launch 2021-08-28 --pref gfx.webrender.all:true -a https://bugzilla.mozilla.org/attachment.cgi?id=9236904
MOZ_ENABLE_WAYLAND=1 mozregression --launch 2021-08-28 --pref gfx.webrender.all:true -a https://bugzilla.mozilla.org/attachment.cgi?id=9236904
MOZ_ENABLE_WAYLAND=1 mozregression --launch 2021-08-28 --pref gfx.webrender.all:true gfx.webrender.compositor:true -a https://bugzilla.mozilla.org/attachment.cgi?id=9236904

Not reproducible:
with layers.async-pan-zoom.enabled:false

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Attachment: Zoomed in screenshot

Comment 11

[Kestrel]

Can confirm that layers.async-pan-zoom.enabled = false also avoids Bug 1673939 with Fission disabled. Since this bug is very similar and has the same regression window per Comment 2, I think it's fair to say that it is also regressed by Bug 1545006.

Comment 13

[Glenn Watson [:gw]]

Unassigning for now, as I'm not actively working on this right now.

Comment 16

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

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1667534: S3

:bhood, could you consider increasing the severity of this bug to S3?

For more information, please visit auto_nag documentation.

Comment 19

[Julien Wajsberg [:julienw]]

This is affecting the profiler's marker table when there are a a lot of markers (and probably the call tree as well, when there are a lot of nodes that are all expanded -- althuogh they start closed at first so probably less of an issue for the call tree) (see bug 1883277 for an example)