1662521 - gfx.webrender.all=true slows down Firefox dramatically (Mate/X11 on Intel HD Graphics 515 (SKL GT2))

Status: RESOLVED WORKSFORME

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

Description

[star]

Attachment: ff_about_support.txt

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

Steps to reproduce:

I just have to do this setting and restart.

Actual results:

It take ages to redraw the window (first nothing happens, but than after around 1 minute) the new window is drawn.

I refer to this
https://bugzilla.mozilla.org/show_bug.cgi?id=1619523#c58

and filed that bug as recommended by
Darkspirit, Servo QA

Expected results:

It should work at least not so slow.

Comment 1

[Robert Mader [:rmader]]

Could have something to do with Mate - you don't happen to have desktop compositing disabled?

Comment 2

[star]

It is indeed Mate and it is running with intel driver (instead of the default modeset-driver).
I don't know what desktop compositing is and how to disable it. Can you tell me how to check? I am not an expert ...

Comment 3

[Robert Mader [:rmader]]

It should be enabled by default, but you could check here: https://wiki.archlinux.org/index.php/MATE#Disabling_compositing

Checking if changing to modeset-driver makes a difference would also be interesting.

Comment 4

[star]

It is enabled: gsettings get org.mate.Marco.general compositing-manager returns true

There is a reason why I use intel driver instead of the modeset-driver. There is unfortunatly some tearing that doesn't make fun with modeset.
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1888810
If someone has a solution for that: welcome ;)

Comment 5

[Robert Mader [:rmader]]

The point would be to find out where the issue is. There's a big chance it's not an Firefox issue, so if you could play around a bit with DEs/drivers/settings to find out if this is only happens on Mate/intel x11 driver/some setting - then we could probably find the root cause and either fix Firefox or forward the bug to the respective project :)

Comment 6

[star]

With modeset driver this issue does not happen. So it becomes even less likely to get video acceleration working for me :(

Comment 7

[Robert Mader [:rmader]]

(In reply to star from comment #6)

With modeset driver this issue does not happen.

So that sounds to me like there are the following possibilities:

• try nightly, especially with the EGL backend (setting the MOZ_X11_EGL=1 environment variable) - might help
• file a bug for the intel x11 driver about this
• file a bug at mate to work properly with the modeset driver without tearing

Comment 8

[Darkspirit]

Does this problem still occur?

Comment 9

[star]

Sorry, I gave up my attempts to get a hardware-accelerated video playback.
I moved to Linux Mint 20.2 but without any deeper adjustments CPU consumption for playback is still high.
Maybe because I don't have Wayland?

Comment 10

[Darkspirit]

This bug was not directly about video or hardware video decoding.
gfx.webrender.all is force-enabling OpenGL hardware rendering - which should perform better and make scrolling smooth.

(star from bug 1619523 comment #58)

Oh, setting gfx.webrender.all=true was a really bad idea. My ff gets so slow, I thought it is completely dead. Needed few minutes to revert that ;)

(star from comment #0)

It take ages to redraw the window (first nothing happens, but than after around 1 minute) the new window is drawn.

1. Do you know if you had multiple Firefox windows open when this problem occured?
2. What does "Compositing" currently say on your about:support page? "WebRender", "WebRender (Software)" or "Basic"? Does it perform good?

Comment 11

[star]

Sorry my bad. I just followed (blindly) some tips. Battery of Laptop doesn't last long while watching TV/Video via browser while mpv almost needs no CPU.

I can confirm that this setting doesn't cause slowdowns anymore.
Stupid question: Is a restart of FF needed after change of this settings?

Anyhow, It think it is difficult to decide whether this has an effect.
to 1) I don't think so. Usually I have just one window but 100 tabs open.
to 2)
dom.animations-api.compositing.enabled true
layers.compositing-tiles.height 1024
layers.compositing-tiles.width 1024

Comment 12

[Darkspirit]

(In reply to star from comment #11)

Stupid question: Is a restart of FF needed after change of this settings?

Yes.

to 2)
dom.animations-api.compositing.enabled true
layers.compositing-tiles.height 1024
layers.compositing-tiles.width 1024

No, about:support, not about:config.
I wanted to know if you might already have hardware WebRender.
Setting gfx.webrender.all to true should have no effect as it should already be enabled by default for you.
You have answered my question:

I can confirm that this setting doesn't cause slowdowns anymore.

Perfect! Thanks :)

Battery of Laptop doesn't last long while watching TV/Video via browser while mpv almost needs no CPU.

Yesterday, we have enabled EGL by default for X11 on Mesa 21 (bug 1695933). Hopefully it sticks. So far we have not received any complaints.
Next steps would be moving VAAPI hardware video decoding into the GPU process (bug 1683808), enabling the GPU process (bug 1653444) and enabling VAAPI hardware video decoding by default.

Comment 13

[star]

gfx.webrender.all was not enabled by default (why ever), so I forced to to enable now.
Not sure it helps.

OK, about:support gives a huge amount of data.
Compositing shows WebRender
Ah, you mean it uses webrenderer despite the gfx.webrender.all if not forced to true?

EGL - I have no idea what does it all mean ;)
But sounds promising. What version I have to wait for and what to set than?

Thanks to you supporting this project!

Comment 14

[Robert Mader [:rmader]]

(In reply to star from comment #13)

Ah, you mean it uses webrenderer despite the gfx.webrender.all if not forced to true?

Yes, that should be the case. gfx.webrender.all just forces things on if not enabled by default.

EGL - I have no idea what does it all mean ;)
But sounds promising. What version I have to wait for and what to set than?

Latest nightly from today. It's the most important step to have accelerated video decoding and also activates much faster WebGL via DmaBuf by default (noticeable e.g. when zooming on Google Maps).

Thanks to you supporting this project!

Thank you for supporting as well :)