Closed Bug 1191775 Opened 9 years ago Closed 9 years ago

Firefox causes Xorg High CPU usage to see the GitHub 404 page animation

Categories

(Core :: Graphics, defect)

39 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: wolfsage, Unassigned)

References

Details

(Whiteboard: [gfx-noted])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150629114917 Steps to reproduce: Navigate to https://github.com/blahsasdfasdfadsfsda Open up top in another window. Move the mouse around the Octocat to see the GitHub 404 page animation. Actual results: The animation is really slow and choppy, and top shows that Xorg is using 90% + CPU. Expected results: Xorg should not be using so much CPU (if any, really, at all) to do this simple animation in Firefox. This is Firefox 39 for Ubuntu 14.10, with Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) using the i915 kernel driver. Note that if I use chromium-browser and repeat these steps, I have no issues at all. I've noticed a few different websites where Firefox has this problem and chromium-browser is always fine.
Retriage if the component is wrong.
Component: Untriaged → Layout
Product: Firefox → Core
Summary: Firefox causes Xorg High CPU usage → Firefox causes Xorg High CPU usage to see the GitHub 404 page animation
I think this is bug in html5 animantion render https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1487980
Component: Layout → Graphics
Flags: needinfo?(lsalzman)
Whiteboard: [gfx-noted]
If you try toggling the following prefs in about:config, then restarting, does it help? layers.use-image-offscreen-surfaces gfx.xrender.enabled Try each individually one at a time. layers.use-image-offscreen-surfaces normally defaults to false in your version of firefox, and gfx.xrender.enable defaults to true. Note that you will have to create the layers.use-image-offscreen-surfaces pref, as we don't have it listed by default.
Flags: needinfo?(lsalzman) → needinfo?(wolfsage)
I am hoping that disabling xrender painting fixed this, but let's see if the reporter still has the issue with layers.use-image-offscreen-surfaces set to true (now default in nightly).
Depends on: 1180942
I eventually found a forum post that pointed to gfx.xrender.enabled. Disabling that seems to have fixed it. Leaving gfx.xrender.enabled at its default and setting layers.use-image-offscreen-surfaces to true didn't help at all. Thanks.
Flags: needinfo?(wolfsage)
Depends on: 1241832
I've starting having the same issue recently (a month?) with other pages. Setting gfx.xrender.enabled to false in Nightly fixed it (I'm running 47.0a1 20160205030204 i.e. today's nightly). One thing that triggers it every single time is the spinning wheel of Confluence, for ex. on https://mana.mozilla.org/ go to a page you own, click the tool/hamburger menu on the page and select "move" => Xorg goes to 99% CPU and everything crawls to death until I kill Firefox - again that's only with gfx.xrender.enabled=True. Turned off, no problem.
https://web.whatsapp.com/ (dead easy to trigger by clicking on your profile face, and editing your status) exhibits this on FF45 (using Debian's 45.0.1-1~bpo80+1) regardless of whether I am running in safe-mode or with all the extensions I have disabled. This has happened for the past two or so versions of Firefox at least. Setting gfx.xrender.enabled to false works for me (Xorg CPU usage drops from 100% to 0%), though CPU usage stays at 100% in Firefox, it no longer drags Xorg to its heels and makes everything un-usable. Interestingly, though whilst Firefox is pegging at 100% CPU usage, it still is responsive to flip to other tabs, and when https://web.whatsapp.com/ is on an inactive tab the CPU starts idling again. After a while (30 seconds or so), that page seems to settle down too. I also tried 'env MOZ_DISABLE_IMAGE_OPTIMIZE=1 firefox' as suggested in http://lists.freebsd.org/pipermail/freebsd-x11/2013-December/013876.html for what its worth, no effect.
Starting in Firefox 47, gfx.xrender.enabled is false by default. This is a big enough change that I don't think we should risk uplifting it but it should be fixed in nightly through the combination of bug 1180942 and bug 1241832.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
No longer depends on: 1263222
You need to log in before you can comment on or make changes to this bug.