Open Bug 1122905 Opened 8 years ago Updated 5 years ago

Firefox permanently using 70% to 100% of CPU on some graphical websites

Categories

(Core :: Graphics, defect, P3)

35 Branch
x86_64
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: mozilla, Unassigned)

Details

(Whiteboard: [gfx-noted])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

Open http://graphics.thomsonreuters.com/14/journalist-deaths/index.html and then click on "By location" link
or
Open https://material.angularjs.org/#/demo/material.components.progressCircular or https://material.angularjs.org/#/demo/material.components.progressLinear


Actual results:

Firefox uses nearly 100% of a CPU core and the animations could be quite slow.
This is permanent: it is not a temporary CPU pick.


Expected results:

I believe that the Firefox process should not use 100% of CPU core to display a spinner or some simple animation.
What is your gfx.color_management.mode setting?  Does setting it to 0 (in about:config) help?
gfx.color_management.mode was 2 (default value).
I tried 0 but it's not better...
Anyway thanks for your assistance! :)
Same issue for me, Core 0 maxed out by FF on the first link.

Changing gfx.color_management.mode to 0 helped slightly, but not enough.
Component: Untriaged → Graphics
Product: Firefox → Core
This bug doesn't seem to occur on Windows accelerated at least. Can you reproduce this on Linux, Nical?
Flags: needinfo?(nical.bugzilla)
Whiteboard: [gfx-noted]
(In reply to Bas Schouten (:bas.schouten) from comment #4)
> This bug doesn't seem to occur on Windows accelerated at least. Can you
> reproduce this on Linux, Nical?

Yes, I just tried the first link (http://graphics.thomsonreuters.com/14/journalist-deaths/index.html ) and it's not too surprising: There is a large svg element which being animated and invalidated every frame, with a lot of display items.
With software rendering, it's not too surprising that the CPU is maxed out in this kind of situation, although we could do much better. For what it's worth, chrome also uses 100% of the cpu although it achieves a noticeably better frame rate.
The page keeps being redrawn constantly for a while after the animation seems to have stopped (maybe 15 seconds or so), apparently the script is still touching the position of the red dots even if resetting the same position or something like this. It eventually stops, though.

Profiling shows that we spend 85% of the time painting, see http://people.mozilla.org/~bgirard/cleopatra/#report=9154329476ec57f08deb4d78b341495f86bf3bd3&selection=0,1,2,27,76,77,81,86,87,88,522,91
Flags: needinfo?(nical.bugzilla)
I can't reproduce the issue with the other two links (material design stuff), but it's quite different in term of what the page asks the browser to do.
So maybe the real bug is with the two links from https://material.angularjs.org if you can't reproduce it.

Anything I can do to help? Any test?
(In reply to mozilla from comment #7)
> So maybe the real bug is with the two links from
> https://material.angularjs.org if you can't reproduce it.
> 
> Anything I can do to help? Any test?

You can record a profile of the issue using the gecko profiler addon which you can get here: https://github.com/bgirard/Gecko-Profiler-Addon/blob/master/geckoprofiler.xpi?raw=true

Instructions about how to use it: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

Then share the profile (as the above mdn page shows) and past the link to the shared profile here so that we can have a look at what's happening in your configuration when the issue occurs.

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