Cloning from bug 1404042 comment 85. (In reply to Mark from comment #85) > I wonder if this sheds any light on anything, or if anyone can replicate my > experience. > > Firefox on my 13" 2013 retina MBP Core i5 / Iris / MacOS 10.13.1 puts > massive strain on the GPU when the Firefox window is frontmost and Firefox > is animating or scrolling. The CPU load is moderate ~70% (out of 400% max). > iStat Menus tells me the GPU is drawing ~15 Watts and the CPU ~4 Watts. With > Chrome and Safari the same site has the GPU ~3 Watts. I think it's the GPU > load which spins the fan up, not the CPU load. I can't replicate this high > GPU load on my old WhiteBook with Core2Duo and 10.12.4 so I don't know > whether it's just my Mac, or just 10.13, or whatever. > > Can anyone else replicate high GPU loads on > https://codepen.io/davidhc/pen/nLpJk with a setup similar to mine? > > You could use iStat Menus and look at the GPU die power consumption, or use > System Information > Battery > Amperage with the charger disconnected and > cmd-R for a couple of minutes to get the correct current draw. Any recent > version of Firefox, 57 and 59 both have the same problem for me. Then > compare with Safari and/or Chrome. My Mac at half brightness and running > Firefox draws ~2500 mA or ~30 Watts to run that animation, Chrome and Safari > ~10 W. > > I definitely have a very poor battery life with Firefox. - a couple of hours > if I scroll and animate a lot. Now I know why. Scaling doesn't seem to > affect much.

Yeah I can reproduce a large power difference (20w vs 10w) with Firefox vs Chrome that I see using Intel Power Gadget.

Daniel, does this test case hit any of the recent problems you guys saw with animations?

I see the same huge power draw with just scrolling a page up and down. I posted that test case because it's easier to replicate. I don't think it's CSS animation per se causing the problem, it's the fact that Firefox is moving and changing pixels. Try the same test while repeatedly swiping any non-trivial page up and down, or just cmd-R reloading a page again and again and again. I get the same huge GPU watts in those cases.

Does this problem only occur on Macbooks with Intel Iris graphics?

I don't see it on my 2010 WhiteBook with Core2Duo / NVidia 320M GPU / MacOS 10.12.4 Could be Retina display, could be Iris, could be 10.13 ??? My guess is it's a 10.13.1 thing but I really don't know. Didn't they rewrite the WindowServer to use Metal 2 or something? You guys need to check though, I can't I don't have enough variety of Macs.

I can confirm I have this problem on MacbookPro12,1 (late 2013 MacbookPro 15 with Retina display, Intel Iris Pro graphics)

(In reply to Ben Kelly [:bkelly] from comment #2) > Daniel, does this test case hit any of the recent problems you guys saw with > animations? I'm not sure what the recent problems are, but in any case I'll punt this to hiro/birtles who know significantly more about the current animations implementation than I do.

There is nothing suspicious in the test case. All three animations there are running on the compositor well and those all animations are throttled if the animating elements are scrolled out. One thing I don't quite understand is that on my Linux box the test case is not able to scroll. I needed to modify the original test case to be able to scroll. Here; https://codepen.io/anon/pen/ooJLva So it might be possible that this scrolling way what I did is different from what Mark has been doing. And if it's different, it's possible that the animations are not throttled at all when those animating elements are scrolled out. We have already a case that out-of-view animations can't be yet throttled (bug 1421507).

Sorry, I think we got confused with the scrolling issue. What I was trying to say was, I see the same high GPU power consumption just scrolling any non-trivial page. www.gsmarena.com is a good example. If I repeatedly swipe www.gsmarena.com up and down (fast) in FF57 on my Mac I see the GPU power consumption rise to ~15 W in iStat Menus. Chrome & Safari are ~3 W. So I couldn't scroll the test case either. I tried your modified version of the test case and it worked as expected:- when I scroll the animation out of view the CPU load drops, but the GPU power consumption remains very high even when the animation is out of view.

Correction to comment 9:- when I scroll Hiro's test case animation out of view the GPU load drops to sensible levels. ~20 W with animation in view, <1 W with it out of view.

I think resolution scaling does matter. At the lowest resolution "larger text" the GPU power consumption on the test case is very moderate. At the higher resolutions "more space" the GPU is cooking at ~15 W. The CPU consumption rises too, but the GPU dominates. Could you guys test GPU power consumption with your retina Macs at different display scaling? Cheers. iStat Menus is a good way to get the GPU power consumption, I couldn't see that in the Intel Power Gadget.

This is a long post but I hope some Retina Mac users take the time to read it and try to reproduce what I have seen. Partly just to satisfy my own curiosity! tl;dr version I think this high power consumption is a bug in the way Firefox interacts with Retina upscaling resolutions on my Mac. It leads to very high power consumption & short battery life at high virtual resolutions when Firefox is animating or scrolling pixels. Chrome and Safari don't seem to be affected. If my Mac's internal display is running at a high virtual resolution, Firefox causes very high GPU power consumption when pixels are changing/animating/scrolling. Chrome and Safari do not. If I plug my Mac into an external display, it does not show the same high GPU power consumption even at the same high resolutions which cause problems with the internal display. I think external displays do not use the Retina upscaling, so I think that the high GPU power consumption is caused by the interaction between Firefox and Retina upscaling. I tested this using Firefox/Chrome/Safari at various Retina virtual display resolutions and using iStat Menus to look at the CPU and GPU power consumption as the animation test case https://codepen.io/anon/pen/ooJLva ran on my Mac. As the internal display virtual resolution increases (up to "More Space" in System Preferences > Displays) GPU power consumption with Firefox increases dramatically from ~3 W up to ~20 W. Chrome and Safari do not show this dramatic increase in GPU power consumption with increasing virtual resolution. To put it in simple terms Firefox will run the animation test case on my Mac for about 4.5 hours at the lowest virtual resolution "Larger Text" (1024x640), but for only about 1.5 hours at the highest virtual resolution "More Space" (1680x1050). At "More Space" (1680x1050) my Mac gets hot and the fan gets very loud. Chrome & Safari will run the test case for around 5 hours regardless of virtual resolution & I can't hear the fan. The difference in battery life with Firefox is I think almost entirely due to GPU power consumption. What's REALLY odd is that if I plug the Mac into my external monitor running at the same 1680x1050 resoluton as "More Space", the GPU power consumption with the Firefox animation test case stays very low ~2 W. This is true whether I am running the Mac in "clamshell" mode with the internal display off, or in "mirrored" mode with both internal and external monitors running at 1680x1050. In this latter mirrored case I can see that the Mac's internal display is not upscaling very well and text is jaggy. But the GPU power consumption remains low. So I think this problem is caused by how Firefox interacts with my rMBP's Retina display upscaling when working at the higher resolutions. I don't know if it's just my Mac, or if it's limited to Iris, or MacOS 10.13, or whatever. I don't think it's a Firefox regression, I have seen similar results with Firefoxes back to 52. I hope someone else runs through some of the same tests I have done, I would really like to know if this affects all Retina Macs or just mine. Long version MacBookPro11,1 Retina MacBook Pro 13" late 2013 / Core i5 2.4 GHz / Iris / MacOS 10.13.1 I got iStat Menus 5 free trial from here https://downloads.tomsguide.com/iStat-Menus,0301-67451.html NB iStat Menus is a bit flaky, sometimes the power meters stall and you need to sleep the Mac for >30 seconds to get them going again. Be careful when reading them. Get iStat Menus reporting powers as follows: CPU Package Core *; CPU Package GPU; CPU Package Total * * I think these are the numbers reported by Intel Power Gadget, which does not seem to show the GPU power consumption. IMHO it's worth using iStat Menus to get the GPU power readings. If you are running a very low resolution you may need to hide the time & date in your Mac's menu bar to fit the iStat information in. WebRender OFF https://codepen.io/anon/pen/ooJLva If the screen resolution is very low, I dragged the top edge of the animation frame upwards so that the whole animation is visible. Browser window was kept at about 75% screen width x full screen height for all cases. (this is important - GPU power consumption seems to depend on browser window size). Browser window was kept frontmost when measurements were made. Results Internal display External display ---- increasing resolution ---> @ 1680 x 1050 Power in Watts Larger Default unnamed More Text Space clamshell mirrored Firefox 59 2017-12-01 CPU package Core 1 1 1 2 2 2 CPU package GPU 3 9 18 21 3 3 CPU package Total 7 14 23 27 10 10 Safari 11 CPU package Core 1 1 1 2 CPU package GPU 1 2 3 4 CPU package Total 5 5 7 10 Chrome 62 CPU package Core 1 1 1 3 CPU package GPU 1 1 1 1 CPU package Total 3 5 4 6 I also tested Firefox 52 ESR at a few of these settings and got much the same result. I tried scrolling www.gsmarena.com up and down very fast to load the GPU and got much the same result. So the problem is, as my Mac's internal display moves towards "More Space" (higher virtual resolution) Firefox causes massive GPU power consumption. At "Larger Text" (1024x640) the GPU consumes ~3 W. At "More Space" (1680x1050) it consumes ~21 W. That causes a hot Mac, high fan speeds, and very short battery life. I then plugged my Mac in to an external 1680x1050 display and ran the same tests with the Mac driving just the external monitor i.e. clamshell mode where the Mac lid is closed; and in mirroring mode where the lid is open and both displays show the same picture. The GPU power consumption here was very low, ~3 W, and did not change whether I was in "clamshell" or "mirrored" mode. It might be worth noting that in "mirrored" mode at 1680 x 1050 the Mac's internal display shows very jagged text compared to running "More Space" 1680x1050 with no external display. "Mirrored" mode has jagged text but low GPU power consumption, "More Space" has smooth text but very high GPU power consumption. So I think the problem may be related to how MacOS interpolates images when in high resolution on the internal display???

So I did some investigation of what my cause this: - Disabling window transparency did not have a noticeable effect - Disabling vibrancy did not have a noticeable effect - Disabling all compositing fixed the problem - Increasing the portion of the window that was painting had an impact on Chrome. If the entire window's contents are changing then Chrome's power usage becomes similar to Firefox After some digging around I discovered that Chrome supports using CoreAnimation for compositing. This likely lets them move composition into the window server and do partial presents. It's my suspicion that this accounts for Chrome's ability to have much lower power usage.

Indeed running Chrome with --disable-mac-overlays gives similar power usage to Firefox on https://codepen.io/davidhc/pen/nLpJk. I'd be interested to know if anyone can reproduce large power differences between Firefox and Chrome when running Chrome with --disable-mac-overlays

Jeff, just as an aside, when I load this page:- https://www.theguardian.com/uk It takes many seconds to load, I think because of the youtube stuff at the bottom If I don't interact with the page during loading, for most of those seconds all that is visibly changing is the throbber in the tab bar, the status bar info bottom left, and occasionally small pieces of page content pop in But the GPU load stays very high ~17 W for the whole load period and the Mac gets hot Is the GPU cranked up just to animate the throbber & the status bar? Neither Chrome nor Safari crank up the GPU in the same way during the load period. Of course, they don't show a throbber! Thanks for your time.

Please ignore Comment 15, it's completely wrong. Sorry. Re Comment 14 Jeff, I DO see large GPU power differences between Firefox 59 and Chrome with --disable-mac-overlays When I disable Mac overlays, Chrome rises from 0.5 W GPU power to around 4 W GPU power. But Firefox 59 is at ~19 W GPU power for the same animation and the same window size. A huge power difference. So for me at least, Firefox's lack of Core Animation is not the whole answer (assuming --disable-mac-overlays really does disable Core Animation). So I am back to my original dumb question:- This is a tiny animation occupying ~5% of the screen area. But on Firefox it melts my GPU. On Chrome it doesn't. Why? What happens on a high-DPI Windows machine? cheers & sorry for error Data:- https://codepen.io/davidhc/pen/nLpJk MacBookPro11,1 at 1440x900 Retina resolution, MacOS 10.13.1 CPU power GPU power Chrome default 1 W 0.5 W Chrome --disable-mac-overlays 2 W 4 W Firefox 59 5 W 19 W

Jeff, if you are running very high Retina resolutions the power difference between Firefox and Chrome --disable-mac-overlays might look smaller than it really is. Remember, the GPU has a thermal design limit, for my MacBookPro11,1 I think it is around 20 W. I think it also depends on CPU load because the CPU+GPU platform has to stay within its 28 W (?) Thermal Design Power. When the GPU hits its limit I think it overloads and starts dropping frames. If you are running a 12" Retina MacBook I think the platform TDP is lower so I would guess the GPU thermal limit is ~10 W. So if I run the same test in Comment 17 but at 1680x1050 Retina resolution it looks like this https://codepen.io/davidhc/pen/nLpJk MacBookPro11,1 at 1680x1050 Retina resolution, MacOS 10.13.1, full screen width & height browser window CPU power GPU power Chrome default 1 W 0.5 W Chrome --disable-mac-overlays 2 W 9 W Firefox 59 5 W 20 W <---- GPU limited by thermals not performance I think Which makes the gap between Firefox and Chrome --disable-mac-overlays look relatively small, but I think that is only because my GPU is overloaded, it would like to run up to 30 or 40 W but can't because of thermal constraints. Again if you are running a 12" Retina MacBook you might hit that thermal ceiling at around 10 W. But you probably knew all that already ;) Sorry for so many posts, I am intrigued.

Here's a build with vibrancy and transparency disabled: https://index.taskcluster.net/v1/task/gecko.v2.try.revision.ccae078a8088e96c1b8244c83981b1cc81465ae5.firefox.macosx64-opt/artifacts/public/build/target.dmg Do you want to see if that makes a difference?

Jeff, this looks like a step in the right direction. Good news:- Your special build dramatically reduces my GPU power consumption on loading and scrolling a lot of websites (what I complained about in Comment 16). For example speed scrolling www.mozilla.org was taking ~14 W GPU power on FF59 but in your special build it is down to ~4 W which is comparable to Chrome --disable-mac-overlays. Also it reduces CPU load on WindowServer from around 30% to around 20% CPU which is similar to Chrome & better than Chrome --disable-mac-overlays. I see similar power savings on page load, e.g. www.theguardian.com/uk has reduced from ~14 W to ~4 W during its long page load time. Most web pages seem to show the same dramatic reduction in GPU power consumption, but some do not. www.arstechnica.com is one that is still at ~12 W during loading and speed scrolling. I don't understand why. I also see significant drop in GPU power consumption playing YouTube, from ~7.5 W to ~2.5 W which is comparable with Chrome --disable-mac-overlays. Bad news:- Your special build does NOT dramatically reduce my GPU power consumption on the test case CSS animation. It does reduce it from ~19 W to ~13 W so some progress. It does substantially reduce the load on WindowServer. The more I think about it, the more I think the whole problem is transparency related. It has to be... given Firefox can play a YouTube video across most of the window using a couple of watts of GPU, there's no reason a little CSS animation should demand 14 W from the GPU?? But what do I know... ;) Is it possible that your special build of Firefox does NOT disable transparency for CSS animations? That might explain what I'm seeing. Thanks for your time so far, we're making progress. Happy to help more if you have any ideas. MacBookPro11,1 at 1440x900 Retina resolution, MacOS 10.13.1 WindowServer CPU GPU power Speed scrolling www.mozilla.org Chrome 30% 2 W Chrome --disable-mac-overlays 50% 4 W Firefox 59 30% 14 W <-- Firefox 59 special build 20% 4 W <-- dramatic improvement!!! Test case CSS animation https://codepen.io/davidhc/pen/nLpJk Chrome 16% 0.5 W Chrome --disable-mac-overlays 30% 2 W Firefox 59 30% 18 W <-- Firefox 59 special build 17% 13 W <-- small improvement Watching https://www.youtube.com/watch?v=9Jbbr-hKsrQ not in full screen Chrome 13% 0.7 W Chrome --disable-mac-overlays 18% 2.5 W Firefox 59 23% 7.5 W <-- Firefox 59 special build 13% 2.8 W <-- dramatic improvement!!!

I don't know if it's another clue but I turned WebRender ON in your special build. Much lower power consumption on the animation test case, actually quite competitive. But WebRender performs very badly in the mozilla.org speed scrolling test. Go figure :) MacBookPro11,1 at 1440x900 Retina resolution, MacOS 10.13.1 GPU power Test case CSS animation https://codepen.io/davidhc/pen/nLpJk Firefox 59 18 W Firefox 59 special build 13 W Firefox 59 special build + WebRender 7 W <-- really good! Speed scrolling www.mozilla.org Firefox 59 14 W Firefox 59 special build 4 W Firefox 59 special build + WebRender 14 W <-- not good!

I'm surprised by the WebRender results and don't have a good explanation. Here are two more build that break out the features individually: build-1 https://queue.taskcluster.net/v1/task/LhX-uOgYTZqrdc7H3janSg/runs/0/artifacts/public/build/target.dmg build-2 https://queue.taskcluster.net/v1/task/frgaZANGRjuL52XDCrZrcw/runs/0/artifacts/public/build/target.dmg Mark, can you test with each of those?

See bug 1404042 Comment 101 I think Anthony has the same problem as me. His Retina MacBook Pro 15 with Iris and 10.12.4 consumed 7% battery in 10 minutes. So it would consume 100% battery in a bit over 2 hours. IIRC those MBPs have a 94 Whr battery so his Mac was consuming ~40 W to do the animation. That's about the same as my Mac when we take into consideration his larger screen etc. I think a lot of that ~40 W is going unnecessarily into his Mac's GPU. Anthony... it sounds like you have iStat Menus installed. Could you configure iStat Menus to show GPU power in the menu bar and run the codepen animation again @1440x900 resolution in a full screen Firefox window? That's iStat Menus > Sensors > Power Sensors > CPU Package GPU. Then run the codepen animation again. Be careful! The iStat Menus readings sometimes freeze. If they do, sleep your Mac for >30 seconds. Make sure you are getting "live" power readings from the GPU not "frozen" ones. You don't have to run codepen for 10 minutes, just long enough to be sure of the GPU power. Thanks a lot.

Re Comment 23 Hi again Mark, I ran it with the same configuration as my previous test: the GPU was at 6-8W, but mostly at 7-8W. On a "normal" website (such as bugzilla.mozilla.org), I am at 0.5-1.5W at most (without scrolling). When I scroll however, for example when I go to the Reddit front page and start scrolling then click on the "next" button, the GPU goes up to 20W.

Compared to Safari (v11.0.2), it goes up to only 4-6W for the same action with Reddit. (Sorry for the double post)

Re Comment 24 - that's interesting and not quite what I expected to see.... damn! Thanks a lot. I think there are two issues here. I think I understand the first but do not fully understand the second (1) the Firefox window presents to the MacOS window compositor as transparent. I think that's bad, because the compositor has to do an (unnecessary) transparency calculation on every visible pixel of the Firefox window. When the Firefox window has moving pixels @60 FPS, that transparency calculation stresses the GPU. As the screen resolution and Firefox window size increase, the GPU power consumption becomes huge. I think that is what you and I are seeing when scrolling. If you have the same Iris GPU as me, I think its maximum power is around 20 W so your GPU may be at maximum and dropping frames. Jeff made me a custom build of Firefox which presents to the MacOS compositor as opaque and that build dramatically reduces GPU power consumption when scrolling & when playing YouTube. I'll post my full analysis soon. (2) in the CSS animation case, the MacOS compositor does weird things. It's like Firefox is presenting as transparent again, even though Jeff's special build makes it opaque. If I force MacOS to consider it opaque using a Special Trick, the GPU power drops again. It also depends on what kind of CSS animation is happening. Some of the codepen examples have low GPU power, some of them have very high GPU power, even examples which seem to do the same thing (eg bouncing balls). I don't understand why. I am still working on this, it is hurting my head. These are just my guesses at the moment, I am sure Jeff & team understand MacOS compositing way better than I do!! Thanks again

Re Comment 26 May I ask you how to force disabling vibrancy on Firefox? Thanks.

Re Comment 27, Use build-1.dmg from Comment 22. You can launch it out of the dmg, it will use your existing Firefox profile. I find that it reduces GPU power a lot when loading & scrolling pages. It also reduces GPU power when watching YouTube. I get about an extra hour watching YouTube on battery with build-1 vs stock Firefox 59. I think the GPU power reduction depends on the resolution your screen is set at & the size of the Firefox window. BUT for me build-1.dmg does not reduce GPU power on the CSS animation test case. Which is strange. I have a really strange question for you... If you run the CSS animation https://codepen.io/davidhc/pen/nLpJk in a really big Firefox window, and then cover almost all of the Firefox window with a really big Finder window (so you can only see a few mm of the edge of the Firefox window), does the GPU power consumption change significantly? With Firefox 58b or with build-1.dmg. :)

Re Comment 28 This don't seem to have any effect. The GPU power consumption is at ~13W when the Firefox window is in foreground and at ~3-7W when any other window is in front of it (FF 58b10).

Re Comment 29. Thanks. What happens if you do the same test using the special build-1.dmg from Comment 22?

Re Comment 30 Retesting using build-1: GPU power consumption at ~6-7W. That's weird. haha

Note that the window or not in front of the Firefox one have no effects at all. I am still at ~6-7W max.

Hmmm, that's very very interesting indeed. On my Mac running 10.13.2 & build-1 it DOES matter whether the Firefox window is in front or behind. Can you confirm that this information is correct for you:- GPU power consumption, https://codepen.io/davidhc/pen/nLpJk running in a full screen window @ 1440x900 MacOS 10.12.4 Browser window in front Browser window almost completely hidden Firefox 58b10 ~13 W ~3-7 W build-1 ~6-7 W ~6-7 W (If so I think we have the answer) cheers now

Everything is correct but the macOS version, I am using 10.12.6 (16G1036).

Excellent! I'll write a big post. It's been doing my head in, as we Brits say.

Three issues:- 1 - high GPU power consumption during page loading & speed scrolling (fans kick in, Mac gets hot) 2 - high GPU power consumption during CSS animation (VERY loud fans & hot Mac & short battery life) 3 - high GPU power consumption during YouTube playback (short battery life) Re Issues 1 & 3 loading/scrolling & YouTube playback. Jeff, the answer is, for me, build-1 shows GPU power reduction. build-2 does not. I think most of the problem is that the whole stock Firefox window presents to the MacOS window compositor as transparent. You can see that in Quartz Debug. Which means that the MacOS compositor has to unnecessarily do transparency calculations over every visible pixel of the Firefox window. Transparency calculations are hard work and so the GPU gets stressed. As the screen resolution and Firefox window size increase, the stress on the GPU increases until it overloads and starts dropping frames. Meanwhile my Mac cooks and the battery drops 1% a minute. Maybe this is why different Mac users are experiencing different power consumption problems? Firefox's power consumption on my Mac depends significantly on screen resolution and Firefox window size. Your version of Firefox (build-1) presents as an opaque window. I've confirmed that in Quartz Debug. Comparing the "opaque" build-1 with "transparent" stock Firefox 59 I see a big reduction in GPU power when scrolling www.mozilla.org. Table 1: GPU power from iStat Menus, FPS from Quartz Debug. "Transparent" Firefox 59 (stock) vs "Opaque" Firefox 59 (build-1). www.mozilla.org in a window filling whole screen. Speed scrolling up and down. Transparent Firefox Opaque Firefox 1280x800 4 W 60 FPS 3 W 60 FPS 1440x900 14 W 60 FPS 4 W 60 FPS 1660x1050 20 W 45 FPS <- GPU maxed? 17 W 60 FPS At 1440x900 it takes 10 W extra to composite the "transparent" (stock) Firefox window than the "opaque" (build-1) Firefox. At 1660x1050 my GPU chokes on the "transparent" Firefox 59 and the FPS drops. But "opaque" Firefox build-1 keeps on going at 60 FPS. I see similar results watching YouTube, but the power saving is about half because YouTube runs at about half the 60 FPS of scrolling. I think any moving image on Firefox will show the same power relationship opaque vs transparent. Build-1 is a real benefit for me. It gives me an extra hour watching YouTube and stops my fans spinning up when loading and scrolling in rapid succession. Nice. Another post to follow on CSS animations...

Three issues:- 1 - high GPU power consumption during page loading & speed scrolling (fans kick in, Mac gets hot) 2 - high GPU power consumption during CSS animation (VERY loud fans & hot Mac & short battery life) 3 - high GPU power consumption during YouTube playback (short battery life) Re Issue 2 CSS Animation (see Comment 36 for issues 1 & 3) Based on what tests Anthony very kindly did (comment 29 through comment 33), I think it sounds like either a bug in MacOS 10.13.2, or it is something which just affects my Mac. Maybe??? Table 2: CSS animation case GPU power consumption, https://codepen.io/davidhc/pen/nLpJk running in a full screen window @ 1440x900 MacOS 10.12.6 Browser window in front Browser window almost completely hidden Firefox 58b10 ~13 W ~3-7 W build-1 ~6-7 W ~6-7 W MacOS 10.13.2 Browser window in front Browser window almost completely hidden Firefox 58b10 ~13 W ~3-7 W build-1 ~13 W ~6-7 W I think the difference is transparency, as in Comment 36. Firefox 58b10 presents to MacOS as a transparent window. If Firefox 58b10 is frontmost & animating, MacOS has to do a transparency calculation on every single pixel of the Firefox window. Which uses ~13 W in line with the scrolling results in Comment 36 Table 1. If Firefox 58b10 is almost completely hidden behind a non-transparent window, MacOS does not need to calculate transparency, so the GPU power drops to ~4 W. (I think that residual ~4 W is MacOS doing the Retina upscaling which it needs to do any time a window has animated content. It seems a constant across all browsers Firefox/Safari/Chrome). You see that in both 10.12 and 10.13 results:- the GPU has to work a lot harder when the Firefox 58b10 window is visible than when it is hidden. That's transparency. Jeff created build-1 which presents Firefox as a non-transparent window. For the 10.12.6 machine, it fixes all three issues. MacOS no longer does transparency calculations on the Firefox build-1 window so it does not matter whether it is in front or hidden. The GPU power is at the same low value when doing the CSS animation as it is for the other animation Issues 1 and 3, see Comment 36. BUT on my 10.13.2 machine, build-1 fixes Issues 1 and 3 but NOT Issue 2. I think for some reason build-1 still looks like a transparent window to MacOS, but only when it is running the CSS animation Issue 2. For Issue 2, Build-1 behaves like Firefox 58b10 i.e. it matters whether Firefox is visible or mostly hidden. (Quartz debug shows build-1 as a non-transparent window for all issues, it just does not behave like that). So I guess maybe this is a MacOS 10.13 bug, or it just affects my machine?? IIRC Apple re-wrote some of the compositing software for this version, maybe there is a bug? I am no expert. Jeff will know. Maybe need to test more Retina machines running 10.12 & 10.13 to be sure.

Has anyone who has experienced this problem experienced tab crashes with Firefox? On one of my machines, I will typically hit a point in the day where my Firefox will not work. Anytime I try to open a tab, I get a message saying "gah, tab crashed". This keeps happening even if I quit and restart Firefox. A logout or reboot is required to resolve it. The issue is covered in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1404298 I also have experienced very high CPU (and jet engine fans) on this same machine. The odd thing is I've only had the crashes on this machine, which is a 2015 Macbook Pro 13". If it's the GPU that's causing it, that would kind of make sense, because it's different than my other machines which haven't had this issue. Video playback has been especially problematic for me. Oh, and I do use scaled mode both on my internal monitor (I use the largest resolution possible) and I have an external 4K display, set scaled to the equivalent to 2560x1440 - which is up I think a few notches from default.

Re comment 38... no tab crashes for me. Ever.

I dusted off my old WhiteBook running MacOS 10.12.4 to try to learn more about this. Inconclusive, perhaps because it doesn't do Retina upscaling. But what I CAN replicate across two machines is that turning WebRender ON roughly doubles GPU power consumption for the three issues above, even with the "opaque" version build-1. Seen both on MacOS 10.12.4 and on 10.13. I don't know if that's what you would expect to see, it seems like a lot to me. Maybe it's a clue. Let me know if I can help more.

I think build-1 loads pages faster than stock FF59 or FF57, even avoiding my Mac's throttling issue I raised in bug 1404042 comment 115. If I open both FF59 and build-1 in low resolution mode to avoid throttling, I get consistently ~20% faster page loads in build-1. I wonder if you killing vibrancy has released CPU resources to do other page-loady things? In fact build-1 is my go-to browser:- faster! cooler! smoother! battery-lifier! On my machine it really matches up to Chrome now. Thanks

(In reply to Mark from comment #41) > In fact build-1 is my go-to browser:- faster! cooler! smoother! > battery-lifier! On my machine it really matches up to Chrome now. Thanks for all of your investigation. We're going to look at this more closely next week and try to come up with a solution that we can get out to users soonish.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #42) > (In reply to Mark from comment #41) > > In fact build-1 is my go-to browser:- faster! cooler! smoother! > > battery-lifier! On my machine it really matches up to Chrome now. > > Thanks for all of your investigation. We're going to look at this more > closely next week and try to come up with a solution that we can get out to > users soonish. Thanks, that's awesome! I'm definitely seeing this on my end. Good to know it's being investigated.

Re comment 42 Let me know how I can help. Sorry for so many words.

@Jeff do the fun bit first. Fire up Quartz Debug, set it to Tools > Show Opaque Regions. Play with MacOS. Hardly any of the screen is red (not-opaque). Windows use tricks to avoid redness, e.g. they are only partly red (Chrome, Finder); windows go green (opaque) when they lose focus. I guess they set themselves as isOpaque? Open a Terminal window and play with its opacity. When it hits opacity 100%, it goes green. If re-declares itself as isOpaque to the system???? Just setting alpha = 1.0 for all pixels isn't enough???? Firefox is the - literally - glaring exception. All red, all the time. I think that's the crux of the whole thing. I think red is computationally expensive. Then go and start reading through the acres of garbage I have posted upthread. Good luck.

You're right Mark, and with the Nightly version (build-1), everything is green except the popups (history, menus, etc).

Re comment 37 issue 2, see also bug 1407536. Might be the same thing. The reporter described high CPU but if he got fans spinning and janky scrolling it could be high GPU load as well? 110% CPU alone won't spin up my fan. I went to stripe.com and @ 1440x900 my GPU went bananas, just like issue 2. Even with build-1. Sometimes I had to quit & restart Firefox or hover over an item eg Product to get the GPU really cooking. The bug reporter says he's on MacOS 10.12 so I'm starting to doubt the conclusion that I drew from Anthony's work (that this is bug in MacOS 10.13). I think it's the gear icon above Developers First. It's a crazy complex CSS animation. Shouldn't it throttle when offscreen? I don't think stripe.com is a good test case, there's so much going on there. But I wanted to link to the bug.

So I was able to reproduce a power difference with build-1 vs Nightly. Mark, I agree with your assessment that the problem is very likely the large amount of transparency. Unfortunately, fixing this is not that easy. Mark, can you test with Firefox 57 vs Firefox 56 and let me know if you see a noticeable power difference between the two of them?

No noticeable power difference with FF56 If you were asking about servo/stylo I turned it off in FF57 and it didn't make any difference either. CPU GPU mozilla.org speed scroll test @1440x900 FF56 ~4 W ~11 W FF57 servo ON ~5 W ~11 W FF57 servo OFF ~5 W ~11 W build-1 ~4 W ~4 W <- fixed!! CSS animation https://codepen.io/davidhc/pen/nLpJk @1440x900 FF56 ~4 W ~15 W FF57 servo ON ~5 W ~15 W FF57 servo OFF ~5 W ~15 W build-1 ~5 W ~11 W <- partially fixed! MacBookPro11,1 / MacOS 10.13.2 / iStat Menus 6

More weirdness. Build-1 and 1280x800 only normally uses 4-5 W GPU power on the speed scrolling & CSS animation test. But some pages use dramatically more power:- scrolling https://www.w3schools.com/howto/howto_css_contact_section.asp (I think it's the Google map) the scroll linked box bottom left of https://www.gsmarena.com/ (as it slides into and out of view) dragging or zooming a Google or Bing map Use around 15 W GPU power even on 1280x800. I don't really understand why. This is on MacOS 10.13.2. So for me at least there are a couple of issues as well as transparency:- - the CSS animation case at high scaled resolution (issue 2) and - these scrolling/sliding effects even at unscaled default resolution. cheers now

(In reply to Mark from comment #50) FWIW, we're looking at fixing the transparency issue. I filed bug 1429522 about this.

Happy to Try anything you come up with. I'm following the new bug. I've been noodling & I'm more convinced part of the problem is with MacOS 10.13. Firefox is not the only app using ludicrous amounts of GPU for simple scrolling at default resolution. Preview & Quick Look & Safari inline viewer have the same problem on some (not all) PDFs & Safari on some web pages (ironically, this page is a good example!) I filed a bug with Apple specifically about the Preview power but am not holding my breath. So there may be more than just transparency??? I would love to have two identical Retina machines side by side running 10.12 & 10.13....

Hey Mark, happy new year! I have about 10+ same Macbook Pro 15" running 10.12 and 10.13 at my work. Do you want me to run some tests?

PS: they're all MacBook Pro (Retina, 15-inch, Mid 2015).

Happy New Year to you as well. Not sure it's so happy for Jeff, he has loads of work to do now. I would love you to run some tests but feel like we will go down the rabbit hole and never come out. Oh go on then.... @ default resolution (not scaled) What's the GPU power consumption on MacOS 10.12 and 10.13 when you... 1) open this current page (https://bugzilla.mozilla.org/show_bug.cgi?id=1422090) in a big Safari window. Speed scroll by jiggling up and down. (on 10.13.2 my GPU goes up to ~20 W and scrolling stutters like crazy) 2) open this PDF in Preview with a big window & jiggle scroll fast http://www.fxplus.ac.uk/sites/default/files/documents/fx_plus_financial_statements_2014-15_final_approved.pdf (on 10.13.2 my GPU is up to ~16 W) These both seem insane power consumptions when Safari can scroll nearly any web page using ~4 W GPU & Adobe Reader can scroll the PDF in (2) using ~2 W GPU. All at default resolution, I know scaled resolution is different. Your Intel GPUs are better than mine so the difference between 10.12 and 10.13 (if any) is probably most interesting. cheers now

I’ll try this tomorrow. In the meantime, how do you get the power consumption without iStats Menu?

Ah yeah, I see your problem - you don't want to pay for more copies of iStat Menus??? You could use Intel Power Gadget, it's free. It shows 2x power values, on the left the whole Intel package (CPU + GPU + ancillaries) and on the right IA which is the CPU die alone. The difference between the two is mostly the GPU power. (That's my understanding anyway) eg if package = 28 W (everything in the Intel package) IA = 4 W (CPU) then the GPU is using ~20 W, the ancillaries (memory controller etc) using a few watts That's accurate enough, we just want to know is the GPU power high / medium / low. Good luck

So: Machines: 2 x MacBook Pro (Retina, 15-inch, Mid 2015). Firefox 58.0b16. Power consumption was at ~20-30W on both machines. The IA at 5-15W.

Re: hypothetical MacOS compositing bug - affects Safari too? Another really long post - so sorry - my lack of expertise means I have to use a lot of words to explain concepts. I won't be offended if you ignore me. Caveats:- I know nothing about the subject; I only have one 2013 Retina MacBook Pro running MacOS 10.13, it may be behaving funny; and my understanding of how browsers work might be flawed. If so ignore this post. tl;dr version Back upthread I complained that Jeff’s opaque Firefox build-1 didn’t fix the CSS animation test case we had been using. CSS animations on build-1 still use a lot of GPU power on my Mac. I hypothesised a bug in MacOS causing this. I’ve done some more digging and I think I can reproduce this bug on my Mac across all three browsers (Safari, Chrome, Firefox) in some test cases. I think maybe up to now the Safari case has been obscured by Safari’s use of Core Animation. I’ve tried to negate this by using REALLY BIG animations covering most of the screen, or by scrolling the whole screen contents. When I do this, Safari redlines my GPU on a simple (but large) CSS animation. Just like Firefox. But Chrome does not, its GPU load is very low. If it really is a MacOS bug which affects others and not just me, and it really affects Safari, then maybe it’ll be quickly fixed by Apple. Maybe it's a new regression in 10.13. Who knows? It would be great if someone could try to reproduce this, it's not hard. I have no idea what I'm doing and am paranoid this just affects my Mac. Long version My understanding is that the GPU is “blind” to what the browser is doing. The browser composites & paints on the CPU and just presents MacOS with a window:- a great big rectangle of RGB pixels at eg 60 fps. MacOS composites this window rectangle with the other windows and then paints the result to the LCD screen. MacOS uses the GPU plus the WindowServer CPU process to do this. I hope this understanding is correct. If not, ignore the rest of this post and educate me! Now, when my Retina Mac is running at default (non-scaled) resolution the GPU shouldn’t have to work very hard because no pixel interpolation is required:- there is a 1:1 mapping from the pixels generated by the browser to the pixels of the LCD panel. There should also be no transparency (alpha) and no blur calculation. Simples. So, I think that... - at default resolution, GPU load should be low with any browser because the GPU just has to map (CPU-generated) browser pixels directly to screen pixels, and - the GPU load should be independent of what content is being presented by the browser. The GPU doesn’t care what fancy gymnastics the browser is doing with scrolling, animations, photos. The GPU just sees a big rectangle of RGB pixels every 1/60th of a second. It has no idea what they represent. But that’s not the case on my Mac, so either my assumptions are wrong or my Mac is misbehaving. Core Animation complicates things a bit but as I said above, I think Core Animation’s power advantage is negated when animations cover substantially the whole screen. On my Mac, all three browsers show wildly varying GPU loads for content which seems superficially similar. Chrome seems to come off best, Safari and Firefox the worst. I think the main problem for all the browsers is CSS animation. All these test cases were run on my Retina MacBook Pro 13" late 2013 with Iris graphics, MacBookPro11,1 at DEFAULT resolution 1280x800, MacOS 10.13.2 and with the browser window covering more or less the whole screen. All have GPU power in Watts from iStat Menus and fps from Quartz Debug Baseline case:- scrolling a conventional web page with minimal animations, e.g. www.mozilla.org or www.bbc.co.uk/news Safari 3.5 W / 60 fps Chrome 2.5 W / 60 fps Chrome —disable-mac-overlays 3.5 W / 60 fps Firefox opaque build-1 3.5 W / 60 fps All three browsers stress the GPU only a little bit (my GPU has a peak power of 20 W I think). I see much the same when scrolling in other MacOS apps full screen, eg TextEdit, Calendar. So I think the MacOS compositor needs about 3.5 W GPU power to composite and paint my whole screen at 1280x800 default resolution & 60 fps. So, if the GPU is "blind" to the content of the browser window, the MacOS composition & paint should always use around 3.5 W of GPU regardless of the browser window content. (???) But it doesn't, on my Mac at least Case A:- CSS fading slider https://codepen.io/davidhc/pen/nLpJk zoomed to 300% to cover the whole screen Safari 18 W / 60 fps <---- Ouch! Safari is worse than Firefox, huge GPU load Chrome 3 W / 60 fps Chrome —disable-mac-overlays 4 W / 60 fps Firefox opaque build-1 15 W / 60 fps <---- this is no surprise, I complained before Previously in this test case the animation has been a very small part of the screen. I think this favours Safari's GPU power consumption because it can use Core Animation tricks to allow MacOS to just composite and paint the small fraction of the screen which is animated. Firefox can't do this. To compensate I zoomed the animation to ~300% in all browsers so that the animation fills most of the screen. (NOTE:- if you want to replicate this test across browsers be careful to close the tab with the animation on the other browsers! Even an animating browser window which is fully obscured taxes the GPU! So make sure only one browser is showing this animation at a time.) So, Safari and Firefox opaque build-1 use huge amounts of GPU just to do this simple fading animation when it covers most of the screen. Why? My understanding is it should be no more taxing on the GPU than the scroll case - in either case the browser just presents MacOS with a big rectangle of RGB pixels every 1/60th of a second. And if Safari's huge GPU power is normal, then why can Chrome do the same animation at the same FPS using the (expected?) 4 W of power? Case B:- CSS animation (?) inline with text, fast jiggle up & down scrolling, https://www.w3schools.com/howto/howto_css_contact_section.asp Map of London always visible never visible Safari 16 W / 60 fps 4 W / 60 fps Chrome 4 W / 60 fps 3 W / 60 fps Chrome —disable-mac-overlays 12 W / 60 fps 4 W / 60 fps Firefox opaque build-1 13 W / 60 fps 3 W / 60 fps Just to be clear here I jiggled the content up and down like crazy a few cm and watched the GPU power consumption. In the former case the Google map of London was always visible during the jiggle, in the latter case I scrolled further down the page and jiggled on the text with no part of the London map visible. The GPU load depends dramatically on whether or not the Google map of London is visible or not. Weird? I think the map is a big CSS animation so related to Case A? Similar results to Case A above but here Chrome --disable-mac-overlays suffers the same as Safari and Firefox opaque build-1. So, Safari and Firefox seem to be hit with this power consumption bug when they are showing large CSS animations. Safari comes off worst. Chrome comes off best. My understanding is that --disable-mac-overlays switches off Core Animation and makes Chrome more like Firefox with full screen presenting. And then Chrome suffers as well. I guess the bottom line is, all these browsers can scroll a full screen or show a full screen YouTube video using a couple of Watts GPU power. But Safari in particular ought to know better - how can it redline my GPU just to show a large-ish fade animation? I think I have a MacOS compositor bug. Perhaps it only affects me. But I think it's what causes me to complain about high power consumption on CSS animations. And for me Safari is affected just as badly. I wonder if the compositor is calculating blur on those animations. Blur is really taxing on my GPU. We've already seen MacOS unnecessarily calculating alpha on pixels, maybe it's doing blur as well???? I have seen gamers complaining that 10.13 High Sierra has dramatically reduced FPS in games, just Google "High Sierra low fps". I wonder if they are being hit with the same bug? I wonder if this is a recent regression? https://arstechnica.com/gadgets/2017/09/macos-10-13-high-sierra-the-ars-technica-review/7/ says "High Sierra’s window server, the system process responsible for drawing all the stuff on your screen, runs through Metal now" Again sorry for the very, very long post. Mark

@Jeff Sorry, another long post above. Hope it's worth your while. Just an aside - if the "transparency" and the "CSS animation" issues are real & are bugs in MacOS... it might be worth you spending some time reproducing them, getting a MacOS regression window, & if it's all real reaching out to Apple. It might be that they are about to fix them. I'd hate to think you were about to spend a great deal of time opaquifying Firefox only to find that eg 10.13.3 drops and fixes the bug(s) from Apple's end? Just a thought & cheers

I have a theory about tall of these high CPU / GPU usage issues primarily being complaints about Firefox running in MacOS. At work I have a 13" 2015 MacBook Pro with Intel Iris Graphics 6100. I have a 24" 4K display attached to this and I also use the laptop monitor as a secondary monitor. I have both displays upscaled - external display to 2560x1440 effective (same default real estate as 27" iMac) and internal monitor to 1440x900. When I try to use Firefox at all, my whole office thinks a jet is about to take off in my office. The fans go nuts. From what I can see it's primarily the CPU pegging - it will peg during page loads. The GPU is likely pegging too, but I haven't dug into that too far. I say all this to say, I'm kind of the extreme edge case. Most people are not upscaling their monitors (let alone an external 4K display on a 3 year old laptop). Case in point is that I don't have any noticeable issues on my 5K iMac at home. I'm not upscaling the revolution and the GPU / CPUs are a lot beefier so if there is a problem, it's being papered over by hardware. But my general theory of why this is disproportionally affecting Macs over Windows (and Linux) machines is that almost every single modern mac is now retina. HiDPI is much less common with Windows and Linux. That combined with the fact that on Windows from what I understand that Firefox uses Direct2d and Firefox doesn't seem to be using CoreAnimation on the Mac, and that explains what's going on (IMHO). Unfortunately it appears that the graphics subsystem in Firefox just isn't up to snuff. It's been talked about before (either here or in other similar bugs) that it would be a lot of works to use CoreAnimation - but unless someone has another idea to solve this issue, you may not have a choice. Apple has already done the work for you, why not use it? Just my 2 cents. I hope somehow this gets sorted out though. I want to be able to use Firefox in some capacity, but due to this issue and a number of other bugs I've run into have not really been able to use it effectively in quite some time.

(In reply to charlie.siegel from comment #61) > I have a theory about tall of these high CPU / GPU usage issues primarily > being complaints about Firefox running in MacOS. > > At work I have a 13" 2015 MacBook Pro with Intel Iris Graphics 6100. I have > a 24" 4K display attached to this and I also use the laptop monitor as a > secondary monitor. > > I have both displays upscaled - external display to 2560x1440 effective > (same default real estate as 27" iMac) and internal monitor to 1440x900. > > When I try to use Firefox at all, my whole office thinks a jet is about to > take off in my office. The fans go nuts. From what I can see it's > primarily the CPU pegging - it will peg during page loads. The GPU is > likely pegging too, but I haven't dug into that too far. > > I say all this to say, I'm kind of the extreme edge case. Most people are > not upscaling their monitors (let alone an external 4K display on a 3 year > old laptop). > > Case in point is that I don't have any noticeable issues on my 5K iMac at > home. I'm not upscaling the revolution and the GPU / CPUs are a lot beefier > so if there is a problem, it's being papered over by hardware. > > But my general theory of why this is disproportionally affecting Macs over > Windows (and Linux) machines is that almost every single modern mac is now > retina. HiDPI is much less common with Windows and Linux. That combined > with the fact that on Windows from what I understand that Firefox uses > Direct2d and Firefox doesn't seem to be using CoreAnimation on the Mac, and > that explains what's going on (IMHO). > > Unfortunately it appears that the graphics subsystem in Firefox just isn't > up to snuff. It's been talked about before (either here or in other similar > bugs) that it would be a lot of works to use CoreAnimation - but unless > someone has another idea to solve this issue, you may not have a choice. > Apple has already done the work for you, why not use it? > > Just my 2 cents. I hope somehow this gets sorted out though. I want to be > able to use Firefox in some capacity, but due to this issue and a number of > other bugs I've run into have not really been able to use it effectively in > quite some time. Two other points I forgot to include: 1. I'm on MacOS 10.13.2 now, but I had these same issues on 10.12.6, so I don't necessarily agree this is being caused by an OS bug. 2. I do NOT see these issues in Safari, Chrome, or Vivaldi. The fans rarely if ever spin up to the point where they're audible when I'm using these browsers. They always spin up with Firefox during the initial page load (even with only one tab loaded).

@charlie.siegel Check out Comment 16 and Comment 20 upthread. I think you are being hit with the same transparency issue I was complaining about. Jeff is looking into it (so far with a hacky version of Firefox called build-1 in Comment 22). You could try build-1 and see if it helps with your jet engine problems, it's certainly helped with mine. Be aware it is a hack of a month old Nightly though. I think it goes like this (but I am no expert, nor do I play one on TV)... During page load the problem comes down to the Firefox tab throbber animating at 60 fps which, because of the lack of Core Animation, causes the whole multi-million pixel Firefox window to refresh at 60 fps. Firefox has declared itself as a transparent window so MacOS stresses the GPU calculating transparency on millions of pixels at 60 fps. And because your iGPU gets so hot, the CPU throttles back to keep the Intel package (CPU + iGPU) within its thermal design limit, the CPU slows to a crawl and pegs albeit at a lowered clock frequency. Fixes which work for me - avoid very high scaled resolutions or - open Firefox in Low Resolution mode (cmd-I on it in the Finder and click Low Resolution) or - use build-1 from Comment 22 which eliminates transparency (but be aware it is a hack of a month old Nightly) and/or - get rid of the tab throbber by tweaking the userChrome settings If you do try these and have any feedback why not post here? build-1 still has some issues for me which is what I am writing more long posts about. I don't think a proper elegant transparency fix will land overnight so you may have to buy ear defenders. From what you say it sounds like this bug existed in 10.12 as well, so that's an interesting data point. This thread is horribly long and it's all my fault. I pity you guys having to read it. Sorry. cheers

(In reply to Mark from comment #63) > @charlie.siegel > > Check out Comment 16 and Comment 20 upthread. I think you are being hit with > the same transparency issue I was complaining about. Jeff is looking into it > (so far with a hacky version of Firefox called build-1 in Comment 22). You > could try build-1 and see if it helps with your jet engine problems, it's > certainly helped with mine. Be aware it is a hack of a month old Nightly > though. > > I think it goes like this (but I am no expert, nor do I play one on TV)... > > During page load the problem comes down to the Firefox tab throbber > animating at 60 fps which, because of the lack of Core Animation, causes the > whole multi-million pixel Firefox window to refresh at 60 fps. Firefox has > declared itself as a transparent window so MacOS stresses the GPU > calculating transparency on millions of pixels at 60 fps. And because your > iGPU gets so hot, the CPU throttles back to keep the Intel package (CPU + > iGPU) within its thermal design limit, the CPU slows to a crawl and pegs > albeit at a lowered clock frequency. > > Fixes which work for me > - avoid very high scaled resolutions > or > - open Firefox in Low Resolution mode (cmd-I on it in the Finder and click > Low Resolution) > or > - use build-1 from Comment 22 which eliminates transparency (but be aware it > is a hack of a month old Nightly) > and/or > - get rid of the tab throbber by tweaking the userChrome settings > > If you do try these and have any feedback why not post here? > > build-1 still has some issues for me which is what I am writing more long > posts about. > > I don't think a proper elegant transparency fix will land overnight so you > may have to buy ear defenders. > > From what you say it sounds like this bug existed in 10.12 as well, so > that's an interesting data point. > > This thread is horribly long and it's all my fault. I pity you guys having > to read it. Sorry. > > cheers Interesting idea with low resolution mode. I tried that with the latest Nightly, but it's still happening. The CPU pegs during page loads and the system temp soars to 187 and the fans kick on. Normal running temperature on this system is ~ 130. So maybe something else is going on that isn't related to graphics? Not sure though. This issue was supposed to be fixed in the Nightly that shipped this morning: https://bugzilla.mozilla.org/show_bug.cgi?id=1419079 I was hoping it would help my overall issues, but no dice. Also, just for everyone's benefit. I've tried everything imaginable on my end to resolve this. I've tried every single version that's available (even ESR today - it's terrible though) and lots of fresh profiles with default settings and no extensions. Something is wrong with Firefox on Mac and unfortunately no one at Mozilla seems to be able to figure it out. Unfortunately for now my fix is to not use Firefox.

(In reply to Mark from comment #59) > Re: hypothetical MacOS compositing bug - affects Safari too? > > Another really long post - so sorry - my lack of expertise means I have to > use a lot of words to explain concepts. I won't be offended if you ignore me. I haven't read through your entire post but I can give some information that will help you understand what's going on. When using CoreAnimation a browser doesn't show up as just a simple window of pixels instead of it's tree of layers that are composited using the WindowServer. This means the layers can be adjusted without much effort with the browser. In the case of https://codepen.io/davidhc/pen/nLpJk some browsers are able to 'layerize' what's going on and some can't. If you try https://jrmuizel.github.io/slider-animation.html in Safari it will layerize and should run with much better battery life. Safari is not able to layerize the codepen version presumably because of the complexity of the codepen ui. If you turn on the Debug menu in Safari using the instructions here https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_Safari you can turn on "Show compositing borders" (under Debug > Drawing/Compositing flags). This will show a counter for each layer that goes up everytime that layer's content is painted. On the codepen example it will constantly be going up which means Safari going to be doing a lot more work.

Re Comment 65 Thanks for the info, interesting. So Case A and comparisons with Safari just expose my naivety! Such a fine line between stupid and clever... Anyway how about Case B? I see lots of Case Bs where Firefox (and, sometimes, Chrome --disable-mac-overlays) show high GPU load for some pages or elements on a page and low GPU load for others which are superficially similar. Maybe there's a naive explanation for that too. Sorry to take up your time with naive assumptions :)

Re Comment 164 Charlie, did you try hiding the tab loading throbber? It worked a treat for me. I just did a test at high scaled resolution, here's one of my (in)famous tables 20x back to back page loads of www.theverge.com, uBlock Origin ON, 1680x1050 scaled resolution, internal display, stock Firefox 57, MacBookPro11,1, MacOS 10.13.2, all numbers approximate CPU GPU page load time CPU temp GPU temp fan speed Firefox 57 5 W 18 W ~4.0 s ~90 C ~100 C ~4000 rpm (jet plane) Firefox 57 throbber hidden 10 W 7 W ~1.5 s ~80 C ~80 C ~1300 rpm (inaudible) I see what I said above, my (probably naive!) understanding is the 60 fps tab loading throbber on stock Firefox 57 makes Firefox spit out a multi-million pixel window @60 fps during the whole page load period. The MacOS compositor makes the GPU calculate transparency and interpolation on this window, that's a mazillion calcs per second. This stresses the GPU which takes most of the available Intel package power away from the CPU. The GPU heats to 100 C. The fan goes into jet plane mode. The CPU throttles to 5 W to keep the Intel package within its TDP. It runs at maybe half max power. Page load times get long. The CPU die doesn't get that hot, 90 C is not too bad and some of that heat is probably soaking in from the GPU side. Ironically for me my GPU is so overloaded in stock Firefox 57 @1680x1050 that it's dropping frames, so the 60 fps tab load throbber is only doing ~40 fps! (Using Jeff's opaque Firefox build-1 helps with this but I won't go into details here, I've already posted on it upthread.) Hiding the tab loading throbber undoes a lot of this. The GPU only draws ~7 W. Much more of the total package power is available to the CPU, which goes way faster. Page load times improve dramatically. The GPU stays cool. The fan stays quiet. I hid the throbber by adding the following line to userChrome.css and restarting Firefox .tab-throbber { visibility: hidden !important; } Of course YMMV, my setup is not the same as yours. I can only say what I see. Worksforme. Re your comment about pegging the CPU, my (naive?!) understanding is that Firefox WANTS to peg the CPU. The only way to get fast page loads is to thrash the CPU to within in inch of its life. That's why Firefox now runs on multiple threads. That shouldn't necessarily spin up the fan because it should only be for a few seconds during page load which is not enough time for the fan to spin up. I said it before on the other thread, I can peg both my CPU cores and my fan does not become audible even after several minutes, it only goes to ~2000 rpm which is not loud. But if I peg the GPU (G for George) the fan is audible within 20 seconds and within a minute is a ~4000 rpm jet plane. I don't know why, something to do with different thermal paths from the die(s) to the fan maybe. The problem I have with Firefox on my Mac at high scaled resolution is that it pegs the GPU (G for George) during page load, which is the wrong way round. It should peg the CPU! (I think?)

(In reply to Mark from comment #67) > Re Comment 164 > > Charlie, did you try hiding the tab loading throbber? It worked a treat for > me. > > > > I just did a test at high scaled resolution, here's one of my (in)famous > tables > > 20x back to back page loads of www.theverge.com, uBlock Origin ON, 1680x1050 > scaled resolution, internal display, stock Firefox 57, MacBookPro11,1, MacOS > 10.13.2, all numbers approximate > > CPU GPU page load time CPU temp > GPU temp fan speed > > Firefox 57 5 W 18 W ~4.0 s ~90 C > ~100 C ~4000 rpm (jet plane) > Firefox 57 throbber hidden 10 W 7 W ~1.5 s ~80 C > ~80 C ~1300 rpm (inaudible) > > I see what I said above, my (probably naive!) understanding is the 60 fps > tab loading throbber on stock Firefox 57 makes Firefox spit out a > multi-million pixel window @60 fps during the whole page load period. The > MacOS compositor makes the GPU calculate transparency and interpolation on > this window, that's a mazillion calcs per second. This stresses the GPU > which takes most of the available Intel package power away from the CPU. > The GPU heats to 100 C. The fan goes into jet plane mode. The CPU throttles > to 5 W to keep the Intel package within its TDP. It runs at maybe half max > power. Page load times get long. The CPU die doesn't get that hot, 90 C is > not too bad and some of that heat is probably soaking in from the GPU side. > > Ironically for me my GPU is so overloaded in stock Firefox 57 @1680x1050 > that it's dropping frames, so the 60 fps tab load throbber is only doing ~40 > fps! (Using Jeff's opaque Firefox build-1 helps with this but I won't go > into details here, I've already posted on it upthread.) > > Hiding the tab loading throbber undoes a lot of this. The GPU only draws ~7 > W. Much more of the total package power is available to the CPU, which goes > way faster. Page load times improve dramatically. The GPU stays cool. The > fan stays quiet. > > I hid the throbber by adding the following line to userChrome.css and > restarting Firefox > > .tab-throbber { visibility: hidden !important; } > > Of course YMMV, my setup is not the same as yours. I can only say what I > see. Worksforme. > > Re your comment about pegging the CPU, my (naive?!) understanding is that > Firefox WANTS to peg the CPU. The only way to get fast page loads is to > thrash the CPU to within in inch of its life. That's why Firefox now runs on > multiple threads. That shouldn't necessarily spin up the fan because it > should only be for a few seconds during page load which is not enough time > for the fan to spin up. > > I said it before on the other thread, I can peg both my CPU cores and my fan > does not become audible even after several minutes, it only goes to ~2000 > rpm which is not loud. But if I peg the GPU (G for George) the fan is > audible within 20 seconds and within a minute is a ~4000 rpm jet plane. I > don't know why, something to do with different thermal paths from the die(s) > to the fan maybe. > > The problem I have with Firefox on my Mac at high scaled resolution is that > it pegs the GPU (G for George) during page load, which is the wrong way > round. It should peg the CPU! (I think?) Mark, I disabled the throbber, and so far in some quick testing, you're right! No fans. I think what you had said earlier about the GPU load causing the CPU to thermally throttle is dead on. The CPU still goes up (but doesn't spike in the way it did before) and the fans never kick in. So with that said - what is being done to address this issue? It appears to be directly related to the animation of the throbber (I'm assuming the little page loading line going across the tab is similar, but it goes for a much shorter period of time so it doesn't seem to have a noticable effect). I know there are a bunch of related bugs but I've kind of lost track of them all. If someone could bring me up to speed on the plan for fixing this, I'd appreciate it. Thanks

@Charlie So pleased it worked for you. Even more pleased to be right about something. I love being right. Rarely happens, see Comment 65. Does Firefox seem snappier at page loads? It made a big difference for me. If you wanted to take things further you could try Jeff's build-1 version of Firefox from Comment 22 in addition to removing the throbber. But that's a hack of an obsolete alpha so it might be a step too far for you. It prevents MacOS doing transparency calculations so it offloads the GPU still further. As to what's being done about it I don't work for Mozilla so I don't know. Jeff said the transparency bug was being fixed. Does Mozilla do battery life tests? e.g. load and scroll a range of pages in a loop until battery exhaustion. Or play YouTube. At scaled resolutions. If not, it should do. Battery life tests would show up a lot of this stuff I think. I can summarise what I think is going on, but I think I'll wait until Jeff has pointed out my naivety about my mysterious "CSS animation bug" which I keep going on, and on, and on about ;)

My final comment about the "CSS animation bug" was in no way intended to be a snide comment! I am hugely grateful for guys like Jeff educating me about this stuff and sorry to take up their time with dumb theories.

So MacOS 10.13.3 didn't make any difference to any of these issues that I could see. I re-ran Case B of Comment 59 with WebRender ON and the power consumption issue was reversed:- scrolling the page region with the Google map used low GPU power; scrolling the text-only region below it used very high GPU power. My concern is how hard WebRender will hit my GPU at default resolution let alone 1680x1050. Even at default resolution there are pages (eg www.gsmarena.com) where, with WebRender ON, some animated elements will max out my GPU and cause frame drops. I'm not sure it's WebRender's fault though, it could be MacOS compositor. I guess it's all a bit premature though, I should wait til transparency is fixed and see what's what. cheers

Timothy, this is closely related to the CoreAnimation stuff you're looking in to (Even though in the short-term goals we're not addressing all the issues) so I'm assigning this to you for the moment. You seem like you'll soon have the best handle on this.

Any news on this? I'm getting Firefox displaying the loader on a white page when I have ~6-8 tabs opened at the same time, switching the tabs from time to time. - Macbook Pro 15", mid-2015, 2.2 Ghz, i7, Intel Iris Pro 1536 MB - macOS 10.12.6 - Firefox 59.0 (64-bit)

Bug 1191965 is the probably the first place to look for an improvement.

Anthony, I still think the best short term fix is to run Firefox in Low Resolution Mode. Select FF in Applications, cmd-I, select Open in Low Resolution. It seems to reduce the GPU load dramatically. It gets a bit blurry but it's perfectly useable. Everything seems faster & cooler. If that doesn't work try hiding the tab load throbber, add .tab-throbber { visibility: hidden !important; } to your userChrome.css file. I think it only reduces GPU power during page loads (IIUC the throbber causes the whole Firefox window to refresh @ 60 fps) but I think that's when your Mac really needs to divert all available power to the CPU to keep things snappy. I think it all helps.

Thanks Mark. That is indeed fixed the issue. However, I don't like having Firefox in LR Mode + don't having the throbber. So I've made some changes: disable LR Mode and using this on userChrome.css with a nice non-animated .png (I've noticed animated .png and .gif can heat the GPU too!) : .tab-throbber[busy]::before { content: ""; position: absolute; background-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAgAAAAIACAYAAAD0eNT6AAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAAhOAAAITgBRZYxYAAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAABtCSURBVHja7d19kF11fcdxd0kIiYnRISQIiIABUjBSE8oQEOIUUURtKBqeFFokaqA6oExpBzBjBitghU5bichTQTKoVSwQBMHiDIJg1FoIBWVQYYgGCAKxYEhCdtPv0bOddWVz7+7eh9/vnNcfrxlGycOc35nzebN7995XbNmy5RUAQL24CAAgAAAAAQAACAAAQAAAAAIAABAAAIAAAAAEAAAgAAAAAQC0xSEfe3pC2C3MC+8tzSv/twmuEQgAoBqDPyUcE64La8OWBtaW/27xa6a4hiAAgLyG/8jwzbChidEfzoby9zjSNQUBAKQ9/HPDd8Yw+sMpfs+5rjEIACCt4Z9efum+vw3jP6C//DOmu+YgAIDuj/+c8Hgbh3+o4s+a49qDAAC6N/7Hh/UdHP8BxZ95vDMAAQB0fvzP6cLwD3WOswABAHRu/BcmMP4DjnUmIACA9o//fuGFhAJgvdcEgAAA2jv+24dHExr/AavDDGcEAgBoTwBcnuD4D/iSMwIBALR+/PcJmxMOgL7wJmcFAgBobQCsSHj8B9zirEAAAK0b//kZjP+A+c4MBADQmgBYnlEALHdmIACAsY//+PBcRgFQ/F3HOzsQAMDYAuDwjMZ/wOHODgQAMLYAWJZhACxzdiAAgLEFwIMZBsCDzg4EADC2AFiXYQCsc3YgAIDRj/+kDMd/wCRnCAIAGF0AzMw4AGY6QxAAwOgC4JCMA+AQZwgCABhdAByRcQAc4QxBAAACABAAgAAABAAgAAABAAgAQACAABAAgAAAASAAAAEAAkAAAAIABIAAAAQACAABAAgAEAACABAAIAAEAAgAQAAIABAAgAAQACAAAAEgAEAAAAJAAIAAAASAAAABAAgAAQACABAAgAAABAAgAAABAAgAQAAAAgAEgAAABAAIAAEACAAQAAIAEAAgAAQAIABAAAgAQACAABAAgAAAASAAQAAAAkAAgAAABIAAAAEACAABAAIAEAACAAQAIAAEAAgAQAAIABAAgAAABAAgAAABAAgAQAAAAgAQACAABAAgAEAACABAAIAAEACAAAABIAAAAQACQAAAAqCbjv7MpnFhp7BPmBF6XRcEAPzen520sjfMCPuEncI410UA5Dj2U8PCcE14IDwd+sOWQTaHJ8N94dLw7jDR9UMAUIOxnxjeHS4N94Unw+awZZD+8HR4IFwTFoaprp8ASPW/8BeFO8KmIWPfrPXh5jIeelxXBAAVGv2ecsRvDuuHjH2zNoU7wiJfIRAAKQx/b3h/+NkoR384Pw5HusYIACow/keGH49y9Ifzs/D+4lsHrrEA6Mb4HxZWtXj4h7o7zHG9BYAAIMPhnxPubvHwD7UqHOZ6C4BOjv+Zoa/N4z/4WwMnuO4CQACQ0fifMIYv9Y9UXzjTdRcA7R7+CeWL+7Z0wfl+ekAACAAyeDX/+R0a/qGKFwtOcA4CoB3j/5pwb5fGf8BNYZLzEAACgATHf1K4qUvjP+De8BrnIQBaOf7bhNu7PP4D7hABAkAAkOD439Hl8R9we9jGuQiAVgXARYmMvwgQAAIA49/YRc5GALRi/E9MbPxFgAAQABj/xk50RgJgLOO/R3gx0QAQAQJAAGD8h/di2MNZCYDRBsDyhMdfBAgAAYDx37rlzksAjGb8Z3fwZ/1FAAIA49+e9wiY7dwEwEgD4KZMxl8ECAABgPEf3k3OTgCMZPz3zWz8RYAAEAAY/+Ht6wwFQLMBcHamASACBIAAwPj/sbOdowBoNgDuyTgARIAAEAAY/z90j7MUAM2M/7SMXvwnAgSAAMD4N/diwGnOVAA0CoATKjD+IkAACACM/x/yqaoCoGEALKlQAIgAASAAMP6/t8TZCoBGAfCFigWACBAAAoC6j3/hC85XADQKgBsqGAAiQAAIAOo8/oUbnLEAaBQAKysaACJAAAgA6jr+hZXOWQA0CoAfVTgARIAAEADUcfwLP3LWAqBRAKyoeACIAAEgAKjb+BdWOG8B0CgALqtBAIgAASAAqNP4Fy5z5gKgUQAsrUkAiAABIACMf13Gv7DUuQuARgFwSo0CQAQIAAFg/OviFGcvABoFwK41CwARIAAEgPGvg12dvwBoJgJWiQAEgAAw/pWxyvkLgGYD4DM1DAARIAAEgPGvqs+4BwRAswEwr6YBIAIEgAAw/lU0z30gAEYSAfeIAPeBABAAxj9797oPBMBIA+CtNQ4AESAABIDxr4q3uhcEwGgi4DYRIAIEgAAw/tm6zb0gAEYbAHNDvwgQAQJAABj/7PSHue4HATCWCFhS8wAQAQJAABj/HC1xPwiAsQZAT7heBIgAASAAjH82rg897gkB0IoIeGVN3xxIBAgAAWD8s3vTn/BK94QAaGUE7B6eEAEiQAAIAOOfrCfC7u4JAdCOCJglAkSAABAAxj/Z8Z/lnhAAIkAECAABYPyNPwJABIgAASAAjL/xRwCIABEgAASA8Tf+AsBFEAEiQAAIAONv/AUAIkAECAABYPyNvwBABIgAASAAjL/xFwAMHwF7iwARIAAEgPFv+/jv7Z4QACJABNQhAA7OOAAOdobG3/gLgLpFwBoRIAJaFAC7ZxwA3pHN+LfKGuMvAESACKhbAGyXcQBs5wyNv/EXACJABLgvRh8Bz2Y4/s86O+Nv/AWACBABImBsAbAqwwBY5eyMv/EXACJABIiAsQXAxRkGwMXOzvgbfwEgAkSACBhbAByaYQAc6uyMv/EXAIgAETC2AOgNazMa/+Lv2uvsjL/xFwCIABEw9gi4MqMAuNKZGX/jLwAQASKgNQEwN/RnMP7F33F/Z2b8jb8AQASIgNZFwHUZBMBXnZXxN/4CABEgAlr/roAbEx7/TWGmszL+xl8AIAJEQL1+JPASZ2T8jb8AQASIgPYEwOTwQILj/5Mw1RkZf+MvABhZBOwlAkTACCJgj/BMQuP/XNjT2Rj/EYz/Xu4JAYAIEAGji4C3hc0JjH/xd3i7MzH+xl8AIAJEQOci4MNdjoDiz/6wszD+xl8AIAJEQOcj4O3ll+C78WV//+Vv/I2/AEAEiIAuRsCe5YvwOvmCP9/zN/7GXwDQxgj4lQgQAU1GwNTix/DKn8Vv58/5X+LV/sZ/BH5l/AUAIkAEdCYEZhbvxtfitw3uL39Pb/Jj/I2/AEAEiIDEQ2D/8gOE1o7xU/2u9N7+xt/4CwBEgAjILwSKjxI+tHwHwVXh2a0M/rPlv3Nx+Wt8pK/xN/4CABEgAioUBduVnytwcKn45+1cG+Nv/AUAIiB13w7j3BMkMv7jwreNv/EXAIiAzvi8+4FEAuDzxt/4CwBEQGctcj/Q5fFfZPyNvwBABHTexnCQ+4Eujf9BYaPxN/4CABHQHY+Fbd0PdHj8tw2PGX/jLwDoZgTsKQI2ne5eoMMBcLrxX+ntoAUAIqDr1obJ7gU6NP6Tw1rj714QAIiANCxxH9ChAFhi/N0HAgARkI5nwjbuA9o8/tuEZ4w/AgARkJZD3QO0OQAONf4IAERAej7r/GlzAHzW+CMAEAHpecjZ0+YAeMj4IwAQAWna2dnTpvHf2fgjAMgtAn5ZowA40LnTpgA4sEbj/0vjLwAQAblZ4MxpUwAsMP4IAERAuj7ivGlTAHzE+CMAEAHeEAhvAGT8EQCIgISc7ZxpUwCcbfwRAIiAdH3QGdOmAPig8UcAIALS9S7nS5sC4F3GHwFAVSJgZgUjYK6zpU0BMLeC4z/T2QoAREAVxr8vbO9caVMAbB/6jD8CABGQnu87T9ocAd83/ggAREB6znWWtDkAzjX+CABEQHr2c460OQD2M/4IAERAWh51fnQoAh41/ggAREA6PuTs6FAAfMj4IwAQAWl4OIxzbnQoAMaFh40/AgAR0H0LnRcdjoCFxh8BgAjorpWhx1nR4QDoCSuNPwIAEdAdT4fdnBFdioDdwtPGHwFAHSJgdULjvynMdzZ0OQLmh00Jjf9q448AoOoRsNiZkEgELDb+CADqEAFvCD/t8vgvdRYkFgFLuzz+Pw1vcBYIANodAVPDrV0Y/vXhOGdAohFwXFjfhfG/NUx1BggAOhUBveFzHRz/1T7qlwwiYG75pfhOjf/nQq9rjwCgGyHwvvDzNn/E77VhR9ebTCJgx3Btmz86+Ofhfa43AoBuR8D4cFpY0+LxvzHMdo3JNARmhxtbPPxrwmlhvGuMACClEJgUzgh3h82jHP214eowzzWlIiEwL1wd1o5y9DeHu8MZYZJrigAg9RjYPnwgfDncXw57/5CxfzH8ItwVPh0OLF5b4PpR0RDoDQeGT4e7wi/Ci0PGvr8MhfvDl8MHwvauHwKAKnyr4HVhVni1awK/C4NXh1nhdb60jwAAAAQAACAAAAABAAAIAABAAAAAAgAAEAAAIAAAAAEAAAgAAEAAAAACAAAQAACAAAAABAAAIAAAAAEAAAgAAEAAAAACAAAQAACAAAAABAAAIAAAQAAAAAIAABAAAIAAAAAEAAAgAAAAAQAACAAAQAAAAAIAABAAAIAAAAAEAAAgAAAAAQAACAAAQAAAgAAAAAQAACAAAAABAAAIAABAAAAAAgAAEAAAgAAAAPIOgDOveWmXMD8cFz4R/jFcFa6moy4L54VTw1HhgDDZzQ40a/ZRX54cDggLwqnhvHB5uJqOuip8LnwiHBfmh126HgAxKj1h/3JsVoUtJGtDuCUsDjt5wAEvM/o7hcXhlrAhbCFZq8oo2z/0dCwAYkDGh4+G1YY1S/3hznCwhx4QA3JwuDP0G9YsrQ4fDePbGgAxGgvDI0a0Mr4R9vYQhFoO/97hGwa0Mh4JC1seADESrw/3GsxKeilcEHo9FKEWw98bLggvGc1Kuje8viUBUHypODxlKCuveI3AVA9IqPT4Ty2/x28oq+2p4ls7YwqAGISTw0bjWBsPhZkelFDJ8Z8ZHjKOtbExnDyqAIghOMMg1tKvRQBUcvx/bRRr6YwRBUAMwDvDZmNY668E+HYAVOfL/v7Lv742h3c2FQDx4J8V1hlBrwnwwkCoxAv+fM+fdWHWVgOgeMc4P+bHIBd4iELWAXCB8WPQjwlO3loAfMroMeRHBL1PAOT7c/5+1I/BPvWyARAP+hnheaPH0DcL8jCFLAPAm/ww1PNhxssFwCXGjmF422DI7+19DR4v55I/CIB4wO8aNhk6hnGnhypkFQB3GjqGsSnsOjgAzjRyNPgAIZ8iCPl8qp8P9mFrzhwcAHcZORpY7OEKWQTAYgNHA3f9LgDiwT499Bk4Gr0vgIcrZBEAfu6fRvrC9CIAFhk3mrCheJ8ID1hIevwnhw0GjiYsKgJgmXGjSQd4yELSAXCAYaNJy4oAuMGw0aQFHrKQdAAsMGw06YYiAFYaNpp0qocsJB0Apxo2mrSyCIDVho0mnechC0kHwHmGjSatLgJgo2GjSV/0kIWkA+CLho0mbSwC4CnDRpMu9JCFpAPgQsNGk54qAuA+w0aTTveQhaQD4HTDRpPuKwLgFsNGk47xkIWkA+AYw0aTbikC4ArDRpPe4iELSQfAWwwbTbqiCICzDBtNfiDQDA9ZSDoAZvggIJp0VhEAs4wbTfiBByxkEQE/MG40YdbApwH+xMDRwLkerpBFAJxj3Gjgp4M/Dvh8A0cDsz1cIYsAmG3gaOD8wQGwv4FjKx7xYIWsIuARI8dW7P//AVBGwLcMHcM4yUMVsgqAk4wcw/jWwH0yOADeXL7S2+Ax2P2h10MVsgqA3nC/sWOI4idE3vxHAVBGwHUGjyGO8ECFLCPgCIPHENcNvkeGBsAeYb3Ro3SbBylkHQG3GT1K68MewwZAGQHH+FYA4dGwg4coZB0AO4RHjR/F20QPvT9e9qaJB/9SA1hrz/uxP6jUjwU+bwBrbenL3RvDBUBP+LohrO1b/i7w4IRKRcACbxFcW18PPU0HQBkBE8NXDGKtvBhO8MCESkbACeFFg1grXwkTh7snGt40MQif9JqAWlgTDvCghEpHwAFhjWGsxY/7fbLR/dDUTRPDcHR4wUhW1g/Dzh6QUIsI2Dn80EhW1gvh6GbuhaZvmhiIXcKVoc9gVsZT4bQwzoMRahUB48Jp4SmDWRl94cqwS7P3wYhvnBiLfcPNxjNrvw3nhSkehlDrEJgSzgu/NaBZuznsO9LzH/WNE+PxxuIjYssvH3uNQB6jf0M4OUzz8AMGhcC0cHK4QQxk8z3+4ts454Y3jvbcW3LzFN8/DovKjxW+OtweHihfWPYkHfV4GWU3hkvDkvCe4qc6POiAJmJgYnhPWBK+EG4sx2Z1eJKOKl6w+T/h9nB18TG+YVHxOo5WnLUbHgBqyEUAAAEAAAgAAEAAAAACAAAQAACAAAAABAAAIAAAAAEAAAgAAEAAAAACAAAQAACAAAAABAAAIAAAAAEAAAIAABAAAIAAAAAEAAAgAAAAAQAACAAAQAAAAAIAABAAAIAAAAAEAAAgAAAAAQAACAAAQAAAAAIAAAQAACAAAAABAAAIAABAAAAAAgAAEAAAgAAAAAQAACAAAAABAAAIAABAAAAAAgAAEAAAgAAAAAQA7Xf3w33Tw1+FC8OXwrfDg+Gx8P3wH2FZOCe8JWzjugEIAPIc/X3CueXA94UtI/BMWB6OC5NcTwABQPrDv1f4augf4egPZ004NYx3fQEEAOkN/y7h8vBSi4Z/qJ+H94ce1xtAAJDG+L8zrGvT8A+1IrzKdQcQAHR3/M8axff4x+qhsKfrDyAA6PzwTwzXdXj4B3suvMNZAAgAOjf+k8IdXRz/ARvDQc4EQABQn/Ef8ETY2dkACADqM/4DfhC2c0YAAoD6jP+AK5wTgACgXuO/pXzjoT91XgACgPqM/4BbnRmAAKBe4z9gvrMDEADUa/wL33V+AAKAeo3/gNc6RwABQL3Gv3CKswQQANRr/AvXO08AAUC9xr/wv2G8cwUQANRn/Afs5WwBBAD1Gn8/DgggAKjh+BeOc8YAAoB6jX/h484ZQABQr/EvLHXWAAKAeo1/4W+cN4AAoF7jXzjamQMIAONfr/EvzHPuAALA+Ndr/Auvd/YAAsD412v8f+nsAQSA8a/X+Bcuc/4AAsD4189R7gEAAWD862VjmOw+ABAAxr9elrsPAASA8a+XTWEP9wKAADD+9XKJewFAABj/evlt2NH9ACAAjH+9fMz9ACAAjH+9/Jv7AUAAGP96uTdMcE8ACADjXx+/Cq91TwAIAONfH0+EWe4JAAFg/I0/AALA+Bt/AASA8Tf+AAgA42/8ARAAxt/4AwgAjL/xBxAAGH/jDyAAMP7GH0AAYPyNP4AAwPgbfwABgPE3/gACAONv/AEEgPE3/sYfQAAYf+MPgAAw/sYfAAFg/I0/AALA+Bt/AASA8Tf+AAgA42/8ARAAxt/4AyAAjL/xB0AAGH/jDyAAMP7GH0AAYPyNf6Xuz4nhz8NJ4e/CP4evlYp//vvy/yv+nYmuGQgAjL/xz/e+nB4+GG4M60dwjuvLX1P82umuJQgAjL/xz+OenBn+PfS14Fz7yt9rpmsLAgDjb/zTvB+nhX8Jm9pwxpvK33uaaw0CwPgbf+Ofzv14bPhNB867+DOOdc1BABh/42/8u3sv9oR/6MLZF39mjzMAAWD8jT+dvxenlC/W69Y9UPzZU5wFCADjb/zp3L24bfheAvfCPWGCMwEBUOUH7nbG3/gndD9eldA9cY0zAQFQ5Qfutcbf+CdyL56e4L3xt84GBEAVH7hnGn/jn8i9eEjYnOD9UbxfwGHOCARAlR64b0/0gWv86/mK//9K+D5ZFXqdFQiAKjxwZ4Rnjb/xT+R+PD6D++VEZwUCoAoP3H81/sY/oVf9/yKDe+ax4u/qzEAA5PzA3S1sNP7uhUTux8UZ3TuLnRkIgJwfuNcYf/dBQvfjnRndP3c6MxAAuT5sd2/RJ6kZf1pxP+6Q2QtRi7/rDs4OBECOD9wzjD8J3Y+nZHgvneLsQADk+MD9T+NPQvfjigzvpxXODgRAbg/bV7Xp89SNP6O9Jx/L8J56zNmBAMjtYfte409ib/6T40+jbPRxwSAAcnvgnm38Seh+nJbx/TXNGYIAyOmB+3njT0L34+yM77HZzhAEQE4P3OuNPwndj2/L+D57mzMEAZDTA/ce409C9+MRGd9rRzhDEAA5PXD/2/gjAAQACID6PXBvNf4IAAEAAqB+D9yrjD8CQACAAKjfA/fTxh8BIABAANTvgbvY+CMABAAIgPo9cPc2/ggAAQACoJ4P3UeMPwJAAIAAqN9D95+MPwJAAIAAqN9D9zDjjwAQACAA6vfQ7Q0PGn8EgAAAAVC/B+9fGn8EgAAAAVDPh+9K448AEAAgALwWwPgjAAQACICaPIAvNf4IAAEAAqB+D+Dx4bvGHwEgAEAA1O8hPD08bvwRAAIABED9HsRzwrouP1BXG38BIAAAAdD5h/Fe4Sddeph+L+zoHASAAAAEQHceyK8KKzr8IL0ibOv6CwABAAiA7j6Ui3cK/FTY0OYH6G/Cqa65ABAAgABI6+G8a7gqbG7xg7MIi4vCNNdZAAgAQACk+5D+k/C1FnxF4IXyy/2vc10RAIAAyOdh/crwF+WbBzX7Y4MPlx8/fLjv8yMAAAFQjYf3tDA7vCP8dfh4OLF8i+F9wmtcJwQAIAAAAQAIABAAAgAQACAABAAgAEAACABAAIAAEACAAAABIAAAAQACQAAAAgAEgAAAAQAIAAEAAgAQAAIABAAgAAQACABAAAgAEACAABAAIAAAASAAQAAAAgAQAIAAAAQAIAAAAQAIAEAAAAIAEAAgAAQAIABAAAgAQABAZQPgkIwD4BBnCAIAGF0AzMw4AGY6QxAAwOgCYFLGATDJGYIAAEYfAesyHP91zg4EADC2AHgwwwB40NmBAADGFgDLMgyAZc4OBAAwtgA4PMMAONzZgQAAxhYA48NzGY1/8Xcd7+xAAABjj4DlGQXAcmcGAgBoTQDMzygA5jszEABA6yJgRQbjf4uzAgEAtDYA9gmbEx7/vvAmZwUCAGh9BFyecAB8yRmBAADaEwDbh0cTHP/VYYYzAgEAtC8C9gsvJDT+68McZwMCAGh/BCxMKACOdSYgAIDORcA5CYz/Oc4CBADQ+Qg4vvwSfDe+7H+8MwABAHQvAuaExzs4/o/7nj8IACCNCJgergv9bRz+/vLPmO6agwAA0gqBueE7bRj/4vec6xqDAADSDoEjwzfDhjGM/oby9zjSNQUBAOQVAlPCMeWX7tc2Mfpry3+3+DVTXEMQAEA1gmBC2C3MC+8tzSv/twmuEQgAAEAAAAACAAAQAACAAAAABAAAIAAAAAEAAAgAAEAAAAACAABoif8DISN8hQwIU7wAAAAASUVORK5CYII=') !important; background-position: left top; background-repeat: no-repeat; width: 32px; height: 32px; animation: none !important; opacity: 1.0; background-size: 16px 16px; } (sorry for the base64, I couldn't find any appropriate image on chrome://browser/skin/tabbrowser/ and chrome://browser/skin/ )

I also tried reverting to the old throbber which IIUC runs at 30 fps and so maybe reduces GPU power by 50% ??? It worked pretty well for me but it might be machine dependent. /* Revert tab throbber - for Nightly 57 as of 9/20/2017 */ .tab-throbber[busy]::before { background-image: url("chrome://global/skin/icons/loading.png") !important; animation: unset !important; } .tab-throbber[busy]:not([progress])::before { /* Grays the blue during "Connecting" state */ filter: grayscale(100%); }

Dave, can you review this bug for whether it's something the Graphics team is working on? If yes, the QF team will move this bug to qf:f64 and keep the P1.

Nobody is actively working on gfx power usage yet. Comment 77 might be obsolete but otherwise looks like something mconley might be interested in?

Actually, tn is working on bug 1191965 which will help with power usage.

Actually that should be bug 1429522 which tn/mstange is working on.

Just wanted to chime in and say I've been having a lot of battery life / overactive fan issues using Firefox on a Retina MBP 2014, and switching to low resolution mode solved the problem for me. I'll continue using other browsers until this can be fixed, but hopefully this data can help narrow down the issue. I also tried these about:config settings, but they did not solve the issue: - browser.tabs.20FpsThrobber - browser.tabs.30FpsThrobber

Re comment 37 and the "CSS animation bug" causing high GPU power consumption, I think the fix in bug 1467619 has fixed "the CSS animation bug" as well.

For the people on MacBook Pro's I'm wondering if you notice a difference when using the Integrated Intel card vs the Dedicated Nvidia or AMD card? We have gathered some data indicating that the power consumption on the Intel card is twice or more higher then on Nvidia cards (even thought the Intel card is suppose to be the power saving one).

Today I noticed while watching a 1080p 60fps videos on youtube that my gpu is getting hotter. I see that because my gpu fan start spinning. With HWmonitor i see my gpu reach about 50°C (fan automatically start working when gpu reach 50°C) and an average of 20% usage while wathing videos. This not happend with chrome, gpu stays between 40° and 45° and the usage stay under 10%. My setup is: ryzen 1600, asrock ab350m pro4, 8gb RAM corsair, nvidia gtx 1060. Let me know if log or more infos are needed.

xlollomanx, it seems bug 1400000 or bug 1263809.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #86) > xlollomanx, it seems bug 1400000 or bug 1263809. Yes, definitely seems one of them. I forgot to mention that I'm on windows 10 latest stable build and latest nvidia driver

Today reading carefully both issue I realized my problem is very similar to bug 1263809. I'll report there