Asa noticed that Metro Firefox uses some CPU non stop when it is idle, even with a blank profile. Jim and myself both reproduced this. I was seeing 7-10% of CPU usage!!! I think Jim did a preliminary investigation using profiling in Visual Studio and found that it is painting code.
Juan could you get a regression range on this? We think it happened recently.
Blocking story depends on what the regression window finds.
I have been trying to reproduce the problem, but I don't think I see it. I'm using nightly builds you can get from ftp. I went back to 5/02 and worked my way up to tonight's build, but I can't reproduce the 7%-10 CPU usage while idle. My steps: 1. Open Metro Firefox and leave it at the Start page 2. Check Task Manager entry for Nightly 3. Alt-tab between Metro Firefox and the Task Manager I've tried this while having the Google page open. I have not been able to see anything past 5% CPU usage, and if it is the plan Start page in Metro Firefox, I don't see anything past 2%, and it is only temporarily while doing alt-tab. After a few seconds it goes to 0% and the process is listed as suspended. Any suggestions I can follow to try to reproduce this problem?
Anything above zero on Firefox start after it's loaded is a bug. Perhaps it's been around for longer than we imagined? I'll see if I can find a build that doesn't put my cpu under load and report back.
You can try putting Firefox into snapped view so it doesn't suspend.
Depends on: 850019
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect c=tbd u=tbd p=0 [blocked on profiler]
This is still a valid bug with omtc enabled.
Summary: Metro Firefox uses 7-10% of CPU when idle → Defect - Metro Firefox uses 7-10% of CPU when idle
Whiteboard: feature=defect c=tbd u=tbd p=0 [blocked on profiler] → [blocked on profiler] feature=defect c=tbd u=tbd p=0
This is only reproducing for me on the start page, and is definitely paint related.
(In reply to Jim Mathies [:jimm] from comment #9) > This is only reproducing for me on the start page, and is definitely paint > related. Not necessarily painting since the widget isn't being invalidated, but the refresh driver is triggering all sorts of callbacks that don't fire on content.
Two problems here - the css throbber we have in the sync flyout and the png throbber we have in the privacy flyout were continuing to animate despite not being visible. I experimented around with various display / visibility settings but ultimately ended up having to ditch the png and "turn off" the css animation to get this fixed.
Assignee: nobody → jmathies
Comment on attachment 771883 [details] [diff] [review] fix This gives us a nice little performance boost too.
Attachment #771883 - Flags: review?(mbrubeck)
Component: Shell → Browser
Whiteboard: [blocked on profiler] feature=defect c=tbd u=tbd p=0 → feature=defect c=tbd u=tbd p=2
Attachment #771883 - Flags: review?(mbrubeck) → review+
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
User Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:25.0) Gecko/20130717 Firefox/25.0 Build ID: 20130717030207 WFM-Iteration 10 Tested on latest nightly from ftp://ftp.mozilla.org/pub/firefox/nightly/2013/07/2013-07-17-03-02-07-mozilla-central/ using windows 8.1 preview and I see 0% CPU usage with Google page opened in nightly.
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 Build ID: 20130816030205 Built from http://hg.mozilla.org/mozilla-central/rev/1ed5a88cd4d0 WFM Tested on windows 8 using latest nightly for iteration-12. I see 0% CPU usage with Google page opened in nightly
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.