Closed Bug 1650134 Opened 4 years ago Closed 3 years ago

webrender related graphics glitching with hardware acceleration enabled (Intel HD400/Braswell)

Categories

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

79 Branch
Desktop
Linux
defect

Tracking

()

RESOLVED DUPLICATE of bug 1710400

People

(Reporter: rjvbertin, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Run FireFox Developer Edition for a while

Actual results:

Sooner or later I start getting graphics glitches with the default rendering settings, usually they start by visible flickering when I switch virtual desktops, and at some point the entire content rectangle (= the web page itself) disappears for up to 2-3 seconds, giving me a view of whatever is behind the FF window(s). That's probably X11's backingstore showing up.

I have no hard recipe to trigger the glitching but once it's triggered it makes sites like the briskoda.net forum or even github hard if not impossible to use.

Starting up with multi-window, multi-tab session restore gives a similar issue: the content of the 1st window that opens appears normally, but in later window(s) one first sees the background for a while before the content appears.

Expected results:

No flickering, no "cheshire catting", no "peeking at the background" at startup.

I can avoid the cheshiring by disabling hardware acceleration, getting rid of all flickering requires disabling gfx.webrender.all .

Testing with a stock profile suggests that the theming is the/a culprit. With the single other extension disabled ("Plasma Integration", I suspected that one) the issue is still present; disabling the themes too by restarting with add-ons disabled prevents the issue.

This is on a low-end N3150-based notebook with 8Gb RAM, using the embedded GPU (HD 400). As far as I can tell all crucial libraries are well above the minimally required version; let me know what precise versions you'd need to know. Or, if you have an AppImage version that contains all required libraries I could test with that too.

Also, this looks a lot like the issue descriped here:
https://mozillagfx.wordpress.com/2020/02/18/challenge-snitch-on-the-glitch-help-the-graphics-team-track-down-an-interesting-webrender-bug/

Can you attach the contents of your about:support as a text file?

Also, have you noticed if this happens using Nightly or Release?

Flags: needinfo?(rjvbertin)
Blocks: wr-linux
Severity: -- → S3
OS: Unspecified → Linux
Priority: -- → P3
Hardware: Unspecified → Desktop

giving me a view of whatever is behind the FF window(s)
....
..."Plasma Integration"...

I assume this is on KDE then? The first sentence suggests that it could also be a WM / compositor issue, just FTR.

Attached file about:support copied as text (deleted) β€”

Requested information.

Flags: needinfo?(rjvbertin)

No, I haven't yet tried with the nightly build. Testing with the release should be pointless because the issue appeared in 78b9. (In fact, the form at startup probably exists since longer, it looks so much like what you can see on slower or swamped systems that I hardly notice it anymore.)
I presume the nightly can be installed in parallel to the developer edition?

And yes, I'm on KDE (but I use xfwm4 as a WM), and I also first thought it was a WM issue even if I don't see why the WM would cause issues with a specific part of the window content, not the UI part, and not the decoration - when it isn't moving or resizing said windows. Turning off compositing in xfwm4 has no effect though.

Please open about:config, set layers.gpu-process.enabled to false and restart Firefox to test whether this fixes the observed problem. (bug 1572625)

It does look better, at least during virtual desktop swapping (instantaneous, no transition effects on my system). I'd have to run the session for longer to see if the window content no longer starts cheshiring when I'm working in it.

But isn't this essentially the same as turning off hardware acceleration in the regular settings?

Interestingly, I'm not seeing the glitch when I connect over VPN (TigerVNC). I'm not sure what to make of that...

I'm seeing the same flickering in the current Nightly build, suggesting that I'll end up having the same kind of longer drop-out of the entire content rectangle if I work long enough in a session. I did not yet try to confirm that disabling webrender.all or layers.gpu-process has the same effect but I guess there's little reason to suspect it wouldn't.

I notice a libmozwayland.so library. Is it possible (and does it make sense) to test this backend if you don't run a full Wayland desktop session? I currently know how to get a Wayland server via one of Qt5's examples, but I do also have a kwin_wayland which is supposed to be its own server ... if I can figure out how to get it to run under or in parallel to my X11 session.

RenΓ©, is this still reproducible for you?

Flags: needinfo?(rjvbertin)

Yes. But it depends also on the window manager. I've switched back to KWin4 with compositing turned OFF, and that prevents the issue from happening.

(I've also moved to using Waterfox G3 since.)

Flags: needinfo?(rjvbertin)

Trying a kernel/mesa less than 3 years old wouldn't hurt either though.

RenΓ©, if this still reproduces for you, could you post the output of xrandr --listproviders here? This is a potential duplicate of bug 1710400

Flags: needinfo?(rjvbertin)

I've been running Waterfox for quite a while now, which never gave me the same kind of issue. I've also discovered that limiting the compositing features in my WM to use only OpenGL 2.0 or even just XRender prevented similar issues the appear elsewhere (those were never as severe as in Firefox though).

I just ran the current Firefox Dev Edition for a while, with the stock profile, and didn't notice anything out of the ordinary, which is at least a good sign.

> xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x49 cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel

PS: I noticed that the current FF. Dev Edition was significantly faster on the Antutu html5 test than Waterfox 3.2.5, reversing the tables. Is it also faster than the current release Firefox on which Waterfox is based?

Flags: needinfo?(rjvbertin)

name:Intel

Thanks! Marking this as a duplicate of bug 1710400 then. In upcoming releases we'll fall back to use software rendering with that driver, it's simply too broken when used with hardware accelerated apps.

I've been running Waterfox for quite a while now, which never gave me the same kind of issue. I've also discovered that limiting the compositing features in my WM to use only OpenGL 2.0 or even just XRender prevented similar issues the appear elsewhere (those were never as severe as in Firefox though).

I can only strongly recommend you to switch to the modesetting driver and not use the Intel DDX driver any more. That's what most distributions have been doing some time now.

PS: I noticed that the current FF. Dev Edition was significantly faster on the Antutu html5 test than Waterfox 3.2.5, reversing the tables. Is it also faster than the current release Firefox on which Waterfox is based?

Firefox has made significant steps with Webrender and on the JS side. Upcoming releases will make Webrender even faster as the legacy rendering code gets removed, which blocked certain optimizations (and in general there are constant improvement streaming in). So for me this is expected :) I guess Waterfox will get rebased on upstream FF at some point (or backport all that work).

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

(In reply to Robert Mader [:rmader] from comment #15)

Thanks! Marking this as a duplicate of bug 1710400 then. In upcoming releases we'll fall back to use software rendering with that driver, it's simply too broken when used with hardware accelerated apps.

Just the rendering, so other operations like video decoding will remain accelerated (if they were)?

I can only strongly recommend you to switch to the modesetting driver and not use the Intel DDX driver any more. That's what most distributions have been doing some time now.

Would that be comparable to the XRender backend in KWin (which supports certain effects that apparenty require compositing, like making windows semi-transparent durings moves and resizing)?

Firefox has made significant steps with Webrender and on the JS side. ... So for me this is expected :)

It also "helps" that Firefox renders only 1/3 of antutu's SVG test (I'm only seeing the lower of the 3 rectangles, which moves a lot faster presumably because the other 2 are absent).

PS: now if only Firefox had support (like Chrome/ium) to exclude the theme from the synced data. Somehow FF and WF disagree on theme names, so you can't run FF on one host and WF on another if you sync the add-ons (I have an old Mac which runs an OS version that's still supported by Waterfox G3 but not Firefox).

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: