search

pop-os / default-settings

Distribution Default Settings
Other
44 stars 16 forks source link

fix(firefox): Unset layers accceleration and enable gfx.xrender instead #96

Closed mmstick closed 4 years ago

mmstick commented 4 years ago

FIx disappearing windows and choppy refresh rate

jackpot51 commented 4 years ago

Note for testing: we need to test this on serw12 for sure, where the issue was reported. Make sure firefox functions with a site like youtube playing a video through a suspend/resume cycle on AMD, Intel, and NVIDIA graphics systems. Video playback is an easy way to test refresh rate, and also scrolling the page while it is playing a video.

jacobgkau commented 4 years ago

I'm seeing a huge reduction in performance on the serw12 with this change. It's noticeable when watching a YouTube video (playback stutters), but to quantify it, I tried this framerate test: https://www.testufo.com/framerates#count=6&background=stars&pps=960

With layers acceleration, I'm seeing the top row run at 144fps (which makes sense, because it's a 144Hz panel.) After this change, I'm seeing the same row run at 60fps, regularly dropping to ~50fps for a second (and sometimes dipping all the way to 20-30fps after clicking around between some other tabs.)

Not having either of the options enabled results in ~22fps all the time, and gfx.xrender at least seems to prevent the scroll stuttering while not causing the transparent window issue (which I am able to reproduce when layers acceleration is turned on.) I assume we're okay with accepting a 50% performance decrease in order to mitigate the transparency bug? It's a shame not being able to watch a 30fps video smoothly on such a powerful machine.

jacobgkau commented 4 years ago

Setting layout.frame_rate to 144 allows the benchmark I previously linked to run at 144fps with gfx.xrender=true. It also makes a noticeable difference when scrolling through text pages. The only issue is that, as I understand it, setting layout.frame_rate=144 would waste a lot of CPU/GPU cycles on systems with regular 60Hz displays. (The default value is -1, which is supposed to automatically figure out the desired framerate somehow, but I've seen other reports that it incorrectly identifies Linux systems as 60Hz when they're actually higher, which seemed to be what was happening.)

The frame_rate option doesn't stop regular 1080p30 YouTube videos from stuttering, but after going through a lot of other settings to see if anything else might help, this appears to be the best compromise. The transparency issue gets better with WebRender, but text still disappears from tabs and the URL bar upon resume. Restarting GNOME Shell (and Mutter?) seems to bring the window contents back when it becomes distorted, but the issue also occurs in KDE Plasma/Kwin, so it definitely seems like an issue in Firefox and/or the NVIDIA driver.

mmstick commented 4 years ago

That's a disappointment. I wonder how the newly-released Firefox performs.

jacobgkau commented 4 years ago

Firefox 81 is performing the same way:

I did check to make sure NVIDIA driver 455.23 doesn't fix this, and the transparency after suspend/resume issue is still present with that version.

I've tested this PR on:

After this testing, I'd suggest we do set layout.frame_rate to 144 in addition to turning on xrender. This allows our higher-refresh-rate systems to display at (up to) their full refresh rate, and doesn't seem to significantly impact resource usage on the systems with lower refresh rates.

leviport commented 4 years ago

I can confirm similar behavior on the oryp6: the patch fixes disappearing windows but drops the framerate if layout.frame_rate is set back to -1. I am testing after most recent commit which sets it at 144, of course, and it looks good with that change.

Darkspirit commented 3 years ago

(Hi, I'm a Firefox user voluntarily helping with triage and regression testing.)

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1673184#c8, the config of Firefox 82 on PopOS is confusingly broken.

Please don't enable unmaintained legacy gfx.xrender.enabled. It prevents users from force-enabling WebRender (the new OpenGL renderer) on their own (gfx.webrender.all=true). WebRender is required for VAAPI hardware video decoding. gfx.xrender.enabled is disabled since Firefox 46, unmaintained and about to be removed for Fission (one process per origin like Chrome). On Linux, Firefox still uses software rendering by default. This will change.

If you wanted to enable WebRender by default for a certain configuration on your own risk, you could add whitelist entries here: https://searchfox.org/mozilla-central/rev/b757a23d312f5b154887b870447ddfeae8cfcc36/widget/GfxInfoX11.cpp#536

With layers.acceleration, performance is normal,

Previous OpenGL renderer (layers.acceleration.force-enabled) is deprecated, unmaintained and has unfixed bugs. ("Compositing: OpenGL" on about:support) Please don't enable it as well.

but the window glitches and goes transparent after suspend/resume.

WebRender (the new OpenGL renderer) and Google Chrome are affected by the same bug (design decision) of the proprietary Nvidia driver: https://bugzilla.mozilla.org/show_bug.cgi?id=1515253#c18

After RTFM at https://download.nvidia.com/XFree86/Linux-x86_64/455.28/README/powermanagement.html#SystemdConfigur74e29 and following the instructions (e.g. set NVreg_PreserveVideoMemoryAllocations=1 and sudo systemctl enable ...) I was able to restore my Firefox window successfully after resume.

The other two relevant bugs are

(Bugs of the proprietary Nvidia driver are tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=wr-nv-linux)

webrender combined with xrender doesn't seem to perform any better than just xrender.

They can't be combined. gfx.xrender.enabled force-disables WebRender without excuse.

jackpot51 commented 3 years ago

@Darkspirit thanks for the information, we will look into our options on Monday