1852440 - Rounded corners rendered sharp and element drawn with wrong shade [Adreno 680/690]

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Alfredo Ferrarotti [:af]]

Attachment: 2023-09-10.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

Opening a web page (particularly evident in gmail) often produces an incorrect rendering of some graphical elements. This same behaviour also happens opening Enhanced Tracking Protection panel of Firefox settings

Actual results:

Open "Menu button -> Settings -> Privacy & Security" panel. The selected Enhanced Tracking Protection option is incorrectly rendered and overing the mouse makes unexpected rectangles appear in the "shaded" area (se attached screenshot). The issues is present also using a newly created profile. It affects the Windows ARM64 (Italian language) platform on Windows 11 ARM64 (Surface Pro X notebook). A similar installation on Windows 11 64bit does not show the issue.

Expected results:

The page should have been rendered as usual in previous versions of Firefox.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Privacy: Anti-Tracking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Teodor Tanasoaia [:teoxoy]]

Could you attach the content of your about:support?

As I won't be able to reproduce the issue (don't have a Windows ARM64 device), could you also attach more examples of those rendering issues?

Comment 3

[Alfredo Ferrarotti [:af]]

Attachment: about_support

Here the about:support attached.

Comment 4

[Alfredo Ferrarotti [:af]]

about:support attached.

Comment 5

[Alfredo Ferrarotti [:af]]

Attachment: Another example of rendering issue

Comment 6

[Alfredo Ferrarotti [:af]]

Attachment: Hovering the mouse the issue gets worse

Comment 7

[Alfredo Ferrarotti [:af]]

Attachment: As it should be (from firefox 64 bit on an Intel based machine)

Comment 8

[Alfredo Ferrarotti [:af]]

Attachment: Short footage showing the issue.

Comment 9

[Teodor Tanasoaia [:teoxoy]]

Thank you for all the info!
Has this always been an issue or did it start to happen in the latest release?

Comment 10

[Alfredo Ferrarotti [:af]]

It happened in one of latest releases, maybe ver 116. In all previous releases it used to work correctly.
Thank you for your prompt support.

Comment 11

[Teodor Tanasoaia [:teoxoy]]

Can someone with Windows on ARM reproduce this issue?
Since it sounds like it's a regression, do any of the recent patches stick out as a cause for this?

Comment 12

[Brad Werth [:bradwerth]]

Thank you for filing. While we try to reproduce this, it would be helpful if you could run a tool called mozregression to isolate which code change has caused this problem for your setup. Would you please install and run that tool? If all works as intended, then that should pinpoint exactly which code is causing this problem, and that will speed up our fix considerably.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

David, are you able to reproduce this on Windows ARM?

Comment 14

[Alfredo Ferrarotti [:af]]

Attachment: mozregression log

Sorry for the delay. Here the log of mozregression. Actually it identifyed the following commit as the origin of the rgression: "Bug 1830588 - Fix clip on fractional composite prims r=gfx-reviewers,lsalzman" (pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4a8d978dd79cea05113daf84e5da8d33b43182ed&tochange=928b0d1a27d51da8561d2e52e32fe6aa1354d7cb).

Comment 15

[Alfredo Ferrarotti [:af]]

Sorry for the delay. Here the log of mozregression. Actually it identifyed the following commit as the origin of the rgression: "Bug 1830588 - Fix clip on fractional composite prims r=gfx-reviewers,lsalzman" (pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4a8d978dd79cea05113daf84e5da8d33b43182ed&tochange=928b0d1a27d51da8561d2e52e32fe6aa1354d7cb).

Comment 16

[Alfredo Ferrarotti [:af]]

Attachment: mozregression session screenshot

Comment 17

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

Setting Regressed by field after analyzing regression range found by mozregression in comment #15.

Comment 18

[Brad Werth [:bradwerth]]

Alfredo, thanks for this. The mozregression output is very helpful. We still haven't reproduced this but we'll keep trying. For at least some Adreno 680 hardware, there are newer drivers available than what you have installed. Lenovo has the version 30 driver. Would you please update your driver if you are able and try again.

Glenn, the regressor Bug 1830588 seems to be about changing our clip code. That's pretty general. Does anything that we do in this reproduction case (opening the settings for Enhanced Tracking Protection) seem like it would be hitting that path?

Comment 19

[Glenn Watson [:gw]]

It's possible it's hitting that path, perhaps a change in that is triggering a GPU driver bug on the hardware that Alfredo has or something like that. We'll likely need to be able to repro locally to find out what's happening though.

Comment 20

[Jeff Muizelaar [:jrmuizel]]

Bob can you find someone to ask in QA about this?

Comment 21

[Bob Hood [:bhood]]

Ashley will check to see if she has access to a Windows ARM machine. I will reach out to QA and see if that hardware is available.

Comment 22

[Anca Soncutean, Desktop QA]

There are no rendering issues on our side, using both en-US and it builds, used versions - 117.0, 117.0.1, 120.0a1. We tried to reproduce this issue on 3 Windows ARM machines (all with Adreno 630 hardware), two Windows 10, one Windows 11.

Comment 23

[Alfredo Ferrarotti [:af]]

My laptop is a MS Surface Pro X with SQ1 processor running fully updated Windows 11. The issue affects most of the web sites I visit and, as explained in my first report it is also evident in Firefox settings. I will upload a two short videos: the first one taken with Firefox ver. 114 (the last version not presenting the issue that I have installed in a separate folder with a new profile) and the second one taken with the current ver. 118 which, in may case :-(, still shows the incorrect rendering effect. Many thanks for your efforts in trying to understand and solve the issue.

Comment 24

[Alfredo Ferrarotti [:af]]

Attachment: Firefox ver. 114 ... as it should look like.

Comment 25

[Alfredo Ferrarotti [:af]]

Attachment: Firefox ver. 118 ... as it looks like.

Comment 26

[Alfredo Ferrarotti [:af]]

Both videos have been resized to 1080p to be <= 10 MB, the original resolution of the MS Surface Pro X is 2880x1920.

Comment 27

[Glenn Watson [:gw]]

Could you try a couple of tests locally, and let us know the results?

First, go to about:config, set gfx.webrender.compositor to true, restart browser, test.

Second, go to about:config, set gfx.webrender.software to true, restart browser, test.

It might be worth testing all combinations of both those settings, and letting us know what effect those changes have, if any.

Comment 28

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gw, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 29

[Alfredo Ferrarotti [:af]]

Here the results you asked for:

gfx.webrender.compositor = True / gfx.webrender.software = True -> OK
gfx.webrender.compositor = True / gfx.webrender.software = False -> NOK
gfx.webrender.compositor = False / gfx.webrender.software = True -> OK
gfx.webrender.compositor = False / gfx.webrender.software = False -> NOK

... I think we we are on the right track! :-)

Comment 30

[Glenn Watson [:gw]]

OK, so it looks like gfx.webrender.software is what's making the difference. This preference forces rendering to be done by our software SWGL implementation, rather than using the GPU (compositing is still done by the GPU). If this fixes the issue, you can certainly use it as a temporary workaround (though rendering will be slower with this setting, so it may not be reasonable, depending on your hardware).

I suspect it will be a driver bug causing one the shaders to be compiled incorrectly, or something similar. It will unfortunately be difficult to solve without being able to reproduce locally. The driver version you have is from 3-13-2023 - I wonder if it's possible to update that to a newer GPU driver for your hardware?

Comment 31

[Alfredo Ferrarotti [:af]]

Unfortunately no updated GPU driver seems available for the Surface Pro X. For this notebook MS does not foresee to update the drivers manually (https://support.microsoft.com/en-us/surface/download-drivers-and-firmware-for-surface-09bb2e09-2a4b-cb69-0951-078a7739e120) but only through Windows Update for which the system is already udated. :-(

I will disable the GPU rendering to fix momentarily the issue.

Many thanks. I'm available for further testing if this could help solving the issue and progressing in Firefox development.

Comment 32

[Glenn Watson [:gw]]

Interestingly, according to the page at [1] there is an August update which includes new Adreno GPU drivers (27.20.1960.0). Hopefully that might get rolled out to your machine via Windows Update soon.

[1] https://support.microsoft.com/en-us/surface/surface-pro-x-update-history-f7e700e1-73b8-9789-d7d4-aaaa777a6d2d#bkmk_sq2_improvements_and_fixes&ID0EDD=SQ1_processor

Comment 33

[Alfredo Ferrarotti [:af]]

Many thank for pointing me to that information. Unfortunately the August update (by the way, not available for the Italian version) contains the same GPU driver (27.20.1960.0) already included in the July update which is also the version installed on my Surface. MS information is a bit confusing.

Comment 34

[Abisha]

As per the debug in https://support.mozilla.org/en-US/questions/1426918, I too am experiencing the same issue.

There is a slight difference in the device - I'm using a Surface Pro X too, but the 2nd generation with the SQ2 processor, and still experience the same issues. Further, I live in Australia and my device runs the English version of Windows.

Comment 35

[Jeff Muizelaar [:jrmuizel]]

I'm going to try to get something like this hardware.

Comment 37

[Ashley Hale [:ahale]]

I checked and I don't have access to an ARM64 machine, the Surface Go laptop I was thinking of is Intel, so I can't repro this locally. I'm happy to debug it remotely if Jeff gets me access to such a machine :)

Comment 39

[Jeff Muizelaar [:jrmuizel]]

I can reproduce this locally and have the machine hooked up to a PiKVM

Comment 40

[Glenn Watson [:gw]]

It's a slow process debugging remotely and building on that machine, but I have managed to repro it, and confirmed that if I disable the new clip-mask path, the legacy clip-mask paths render correctly on this device. That's not a workable fix, as we want to remove the legacy path, but it does narrow down the driver bug to a bug in compiling 1 or 2 shaders.

Comment 41

[Jim Blandy :jimb]

Hi, Glenn - assigning to you because this came up in triage, and it seems like you're aware of a path forward. Delegate if you think it's appropriate.

Comment 42

[Abisha]

Thought of adding an interesting observation to this - when I plug a second monitor (using a Type-C to VGA dongle) into my Surface Pro X, and drag the same Firefox window over to the external monitor, the issue disappears. When I drag the window back to the Surface's display, the issue comes back. Driver updates to this date have not fixed the issue either (it's been 7 months since the initial post).

Comment 43

[Lili]

Hello!
I'm currently using Firefox Nightly on a Surface Duo (Windows) (Adreno 640 GPU) and it seems to have the same troubles rendering elements that have rounded corners. I'm aware this is not a standard supported configuration and device, but so far Firefox has been the only program that has rendering issues in any capacity. Games, emulators, other browsers and applications have shown no issues.

Driver wise, Surface Duo uses the same drivers as Surface Pro X as the SoC is very similar, and it shares most of the issues with said device. (And many other Snapdragon devices with official Windows support). I might add this issue was introduced by Qualcomm in the 1940 version drivers.

This issue was also reported on Reddit (https://www.reddit.com/r/firefox/comments/182iojx/firefox_arm64_graphical_problems_on_surface_pro_x/) and confirmed that it appeared in the 1940 drivers as rolling back said drivers fixed it.

Comment 44

[foxenesys]

Mmmh...
I have a Surface Pro X with SQ2 Adreno 690.
I rolled back to driver 26.18.1250.0 and everything is fine now.