Closed Bug 1561833 Opened 5 years ago Closed 5 years ago

Media consumption causes huge performance penalty. (67.0.4)

Categories

(Core :: Audio/Video: Playback, defect)

67 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: shalokshalom, Unassigned)

References

()

Details

(Keywords: perf, regression)

Attachments

(2 files)

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

Steps to reproduce:

Visit https://hd-streams.org/movies/star-trek-beyond-2016

Actual results:

https://imgur.com/DNXP8dW

Expected results:

Less CPU usage, as in previous versions.
And here the same page in Chrome:
https://i.imgur.com/Z7tND6V.png

I couldn't reproduce this issue on 67.0.4 20190619235627 on Ubuntu 16.04 x64, with a mid-end configuration (Intel with Integrated GPU).

Could you please check about:support under Graphics if "Compositing" has "webrenderer" as a value?

If the value for "Compositing" is "webrenderer" then please try the following and retest to see if the CPU still stays in the higher output:

            reach about:config and set "gfx.webrender.all.qualified" to false (If the preference is not there add it)
            restart Firefox

If the value for "Compositing" is anything else but "webrenderer", then please add details about your hardware configuration, in order to try debug this issue better. An attachment containing your about:support page would be great as well.

Flags: needinfo?(shalokshalom)

Please open about:support, click on "Copy raw data to clipboard", paste it into a text file and upload it here (Attach File). Thanks!

Keywords: perf
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Flags: needinfo?(shalokshalom)
Summary: hd-streams causes huge performance penalty. (67.0.4) → Media consumption causes huge performance penalty. (67.0.4)
Attached file firefox.txt

about:support

Ok, so since : "adapterDescription": "Intel Open Source Technology Center -- Mesa DRI Intel(R) Ivybridge Mobile ", the webrenderer assumption in comment 1 drops from the radar. Next, might be an add-on incompatibility issue: I've installed most of your add-ons and still could not reproduce the high % processor consumption. I see nothing else that could offer a good lead in the listed about:support paste.

shalokshalom, could you please try to reproduce the issue with safe-mode[1] or with a new profile [2]? If there is no issue with safe-mode or new profile, then the problem can be attributed to something amiss that is at the moment in your profile. It would also be great if you could identify in which version that high % consumption started?

[1]. https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode#w_how-to-start-firefox-in-safe-mode
[2]. https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles#w_creating-a-profile

Flags: needinfo?(shalokshalom)

So far as I am aware, it started in 67.0.4 and it happens in safe mode as well.

Flags: needinfo?(shalokshalom)

Is there anything else I can do?

Firefox is almost unusable for me now.

I had to switch to Chrome :/

Thanks for offering help!
You could try to find a regression range:
https://mozilla.github.io/mozregression/install.html
https://wiki.mozilla.org/Release_Management/Calendar

sudo pacman -S python2-pip
sudo pip2 install -U mozregression
mozregression --good 2019-01-01 --bad 2019-06-27
If needed, you can run mozregression with prefs: --pref gfx.webrender.all:true otherpref:"string" otherpref:12345
You can also launch single builds: mozregression --launch 2019-06-27

If you can't find a regression range it might have been caused by changes on your system.

Apart from that, you should try to manually enforce hardware acceleration (OpenGL): Open about:config, set layers.acceleration.force-enabled to true and restart Firefox.

You could also try out Firefox' new graphics engine:
Download Nightly, open about:config, set gfx.webrender.all to true and restart Nightly. (Linux-only bugs, Report new WebRender bug)

I changed layers.acceleration.force-enabled to true and all is fine now.

Did Firefox change anything recently in this direction or is this system specific?

Since I installed this OS from scratch and it still causes issues without manually enabling gpu acceleration.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Do you think this is OS specific or Firefox specific?

It is on an Intel HD 4000 and I think it happens since mesa-19.0.8

It is in use here since the exact same date as my error report

(In reply to shalokshalom from comment #9)

Do you think this is OS specific or Firefox specific?

It is on an Intel HD 4000 and I think it happens since mesa-19.0.8

It is in use here since the exact same date as my error report

If you could search for a regression range with mozregression via the steps in comment 7 that would help narrow down if something has changed in Firefox.

To clarify: this system used to be fine and since Firefox 67 you've had issues?

Based on existing information it sounds like lack of hardware acceleration is causing the problem.

Flags: needinfo?(shalokshalom)

Hi there :D

Yes, it started recently, in 67.0.4 or 67.0.3

It works fine now, since changed to enforced mode.

I guess hard, this has to do with MESA, will report soon, once the new version is applied.

Flags: needinfo?(shalokshalom)

Setting up NI while we wait to hear back regarding MESA versions. It sounds like the regression is caused by Firefox not defaulting to acceleration, so if you've set layers.acceleration.force-enabled on a profile you may wish to create a new one to see if Firefox defaults to acceleration or not. If you're seeing Firefox not pick up on the need for acceleration where it previously did, it would be helpful if you could use mozregression to find when it stopped doing so.

Flags: needinfo?(shalokshalom)

This has been solved by the new MESA version, thanks a lot.

Flags: needinfo?(shalokshalom)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: