1797622 - Rendering issue with padded backgrounds on Software WebRender on macOS (13?)

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Dennis Schubert [:denschub]]

Attachment: Screenshot 2022-10-26 at 22.33.33.png

With a 2022-10-26 nightly running on a 2021 16-inch MacBook Pro Apple M1 Max with macOS 13.0 (22A380), on Software WebRender (currently due to gfx.blacklist.webrender==8), I see weird issues where the background of a padded element appears to be off.

Attached is a screenshot showing a testcase I built, but also the checkboxes on about:preferences. I will attach the testcase in a second comment.

Note that

• I cannot reproduce this with Hardware WebRender, so this seems to be a Software-WR issue
• This doesn't appear to be a recent regression - I ran a Nightly from 2022-04-04 via mozregression on Software-WR and it reproduced as well
• I can't reproduce this (or at least I can't visually see it) on the MacBooks internal display, but 100% of the time on an 1920x1080px external screen
• I do not know if this is related to macOS 13 or not.

Comment 1

[Dennis Schubert [:denschub]]

Attachment: Testcase shown in the screenshot in comment 0

Comment 2

[Dennis Schubert [:denschub]]

Attachment: about:support

And finally, attaching the about:support data.

But as discovered on Slack, this probably is a dupe of bug 1791495.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Looks like pixel snapping gone bad?

Comment 4

[Jamie Nicol [:jnicol]]

I cannot reproduce on an M2 macbook air. Dennis, could you try running an even older build using mozregression and see if it reproduces?

Comment 5

[Sören Hentzschel]

Attachment: aboutsupport.txt

I can reproduce this issue if I run Windows 11 via Parallels Desktop on my M1 Pro MacBook Pro with macOS 13 (macOS 12 was also affected, I see this issue since the first day I use Parallels, June 30th), but only in Firefox 106.0.2, not in Firefox Nightly. And if I try mozregression I can not reproduce in builds that are older than 106a1. I can also not reproduce if I use the profile from 106.0.2 on Nightly. And I can also not reproduce directly on my MacBook Pro with Software WebRender.

I attached the about:support output of my affected installation.

Bug 1791495 also reproduces for me only on the installation that reproduces this bug.

Comment 6

[Lee Salzman [:lsalzman]]

Sören, are you able to use mozregression to find a fix range using the --find-fix option for this (as opposed to a regression range)? Rather, it would be nice to know if this actually somehow got fixed in a nightly, and what patch did it? Or is there something incidental about the release packaging/chrome that just makes it happen that is not present in nightly? Either way, mozregression would help tell us.

(In reply to Sören Hentzschel from comment #5)

Created attachment 9300920 [details]
aboutsupport.txt

I can reproduce this issue if I run Windows 11 via Parallels Desktop on my M1 Pro MacBook Pro with macOS 13 (macOS 12 was also affected, I see this issue since the first day I use Parallels, June 30th), but only in Firefox 106.0.2, not in Firefox Nightly. And if I try mozregression I can not reproduce in builds that are older than 106a1. I can also not reproduce if I use the profile from 106.0.2 on Nightly. And I can also not reproduce directly on my MacBook Pro with Software WebRender.

I attached the about:support output of my affected installation.

Bug 1791495 also reproduces for me only on the installation that reproduces this bug.

Comment 7

[Sören Hentzschel]

Unfortunately I am not able to reproduce with mozregression at all, neither with old nor with current builds, not even when using the profile from the affected installation. :-(

Is it possible that some blocklisting entry that does not apply in mozregression builds affects a relevant code path?

If I compare the output from about:support of a new profile in Firefox 106.0.3 (with this problem) and a new profile in Firefox Nightly (without this problem) I see the following graphics related differences:

Firefox 106.0.3:
WEBRENDER:
available by default
disabled by env: Not qualified

Firefox Nightly:
WEBRENDER:
available by default
blocklisted by env: Blocklisted by gfxInfo

///

Firefox 106.0.3:
WEBRENDER_QUALIFIED:
available by default
blocklisted by env: No qualified hardware

This section is missing in Firefox Nightly.

///

Firefox 106.0.3:
WEBRENDER_SOFTWARE:
available by default

This section is missing in Firefox Nightly.

///

Firefox 106.0.3:
WEBGPU:
disabled by default: Disabled by default
Blocklisted; failure code BLOCKLIST_FEATURE_FAILURE_UNKNOWN_DEVICE_VENDOR
blocked by runtime: WebGPU cannot be enabled in release or beta

Firefox Nightly:
WEBGPU:
disabled by default: Disabled by default
Blocklisted; failure code BLOCKLIST_FEATURE_FAILURE_UNKNOWN_DEVICE_VENDOR

(the "blocked by runtime" sentence is missing)

///

In the section of the important modified preferences there are the following entries for Firefox 106.0.3 that do not exist for Firefox Nightly:

gfx.crash-guard.d3d11layers.appVersion: 106.0.3
gfx.crash-guard.d3d11layers.deviceID: 0x4005
gfx.crash-guard.d3d11layers.feature-d2d: false
gfx.crash-guard.d3d11layers.feature-d3d11: false
gfx.crash-guard.status.d3d11layers: 2

Firefox Nightly has a reset device button below the GPU information, Firefox 106.0.3 has not.

Comment 8

[Lee Salzman [:lsalzman]]

Do you have the gfx.webrender.software pref set to true in mozregression?

Comment 9

[Dennis Schubert [:denschub]]

I haven't forgot about this issue, but finding the exact regression range is a bit complicated. For now, I know that my regression is somewhere inbetween [2021-01-01, 2021-01-31], or at least I'm fairly certain about that, as it appears to be reproducible. Interestingly, this disagrees with bug 1791495 comment 8.

To narrow that down further, I have to manually bisect code and build myself, so that's going to take some time. I'll try to follow up as soon as I can...

Comment 10

[Lee Salzman [:lsalzman]]

Did the fix for 1791495 (which should now be in the latest nightly build) resolve this bug, by chance?

Comment 11

[Dennis Schubert [:denschub]]

Seems like I cannot reproduce this anymore.