User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171226100306 Steps to reproduce: Open latest Firefox Nightly (26 Dec 2017) Wait for processes to fully load Move mouse pointer in small circles anywhere in Firefox window Notice CPU usage on main process increases dramatically Actual results: CPU usage spikes when moving mouse in Firefox window on Windows 10 v1709 (16299.15125). Hardware - J4205 CPU (Apollo Lake); Intel HD Graphics 505; DirectX12.0 This problem exhibits itself on a blank tab but is much more pronounced on a tab loaded with content. https://www.youtube.com/watch?v=Ni4XV0N5ZSc https://perf-html.io/public/e69aa5a2ced60c7ea4136f45db5caf6bc6490e4b/calltree/?hiddenThreads=&thread=2&threadOrder=0-2-3-4-5-1-6&v=2 Expected results: Reporting in conjuction with Reddit thread here: https://www.reddit.com/r/firefox/comments/7knnn4/firefox_quantum_is_eating_your_cpu_help_us_debug/ Expected minor increase in CPU associated with mouse movements. No other programs on my computer cause CPU to dramatically spike on mouse movement other than firefox. I have tested a variety of 3D and 2D applications. Some minor (e.g., 5-10%) CPU spiking happens in other applications on rapid mouse movement but apart from Firefox, none increase utilization to 100%. I am unsure if this is related to the bug referenced on /r/firefox but it certainly seems like something is amiss with the 2d rendering framework.

There is something a bit odd looking happening with APZ's ReceiveInputEvent, in particular a condvar underneath.

(In reply to Olli Pettay [:smaug] from comment #1) > There is something a bit odd looking happening with APZ's ReceiveInputEvent, > in particular a condvar underneath. I'm assuming that you're looking at the part on the "Main Thread" thread that goes into mozilla::layers::IAPZCTreeManager::ReceiveInputEvent. If I drill down into this function it looks like 89% of the time inside the function is just spent in MessageChannel::WaitForSyncNotify - that is, it's an IPC issue, and the main thread is not able to send the input event over to the compositor thread for it to process. But the compositor thread itself appears to be mostly idle so I'm not sure why this is happening. Overall around 30% of the time in the main thread seems to be spent processing mouse events (~12% in APZ processing, ~17% in dispatching to content) which does seem fairly high.

Let's see if bug 1426653 helps any.

Jonathan, can you grab the upcoming Nightly (with bug 1426653 fixed) and check if your issue is fixed with it? Thanks!

The symptoms remain similar on the 2018-01-10 Nightly for me. I recorded a new screen capture here: https://youtu.be/jueECRkuGqg and an additional perf-html.io test here: https://perfht.ml/2Dhdb9d At the end of the youtube screen capture video, I recorded similar mouse movements in Edge browser as a point of comparison. Using similar mouse movements it uses no more than 25% CPU compared to over 70% in Firefox Nightly. I recorded another perf-html capture (https://perfht.ml/2DfHyg0) a short time after to see what the CPU usage would be without OBS recording in the background. It still will spike to 75% when rapidly moving the mouse on an empty tab. This, however, is an improvement compared to when I initially submitted the bug report as it was capable of going to 95% or more CPU usage previously.

Sorry for the trouble, I meant the Nightly that comes after that. Just to be sure, can you retest on a Nightly from 2018-01-11? No need to record or profile if the behavior is the same.

2018-01-10 should have the fix in bug 1426653; about:buildconfig says it was built from https://hg.mozilla.org/mozilla-central/rev/d5f42a23909eb181274731b07e4984bfbd18557d which contains the fix.

Looking through the second profile in comment 5 I noticed that the mousemove events are actually being dispatched to some js code running in browser.js:8684, which is in some MousePosTracker thingy [1]. I don't know what it's for but having that listener likely means we're spending a bunch of time dispatching the event that could be avoided if there are no listeners (I think we have this optimization for some kinds of events, not sure if we have it for mousemove). [1] https://searchfox.org/mozilla-central/rev/03877052c151a8f062eea177f684a2743cd7b1d5/browser/base/content/browser.js#8684

Another small chunk of time (per the profile) is spent dispatching a pointer event from the mouse event. Presumably that's something we can optimize away if we know there are no pointermove listeners?

Ah, ok, cancelling the NI.

Aaand NI on :dao because since he's the author of the code mentioned in comment 8. :dao - any chance we can optimize that?

We use MousePosTracker to move the status panel (that displays link URLs) to the other side when the mouse pointer is close. We listen to mousemove events before we even display the status panel, so that we already know the pointer position when we want to display the panel. I'm not sure how this could be optimized away without compromising the UX.

Since we track the mouse location directly in the presshell anyway we could expose a DOMWindowUtils API to get the mouse location. Maybe I'll do a try push first with that listener removed for Jonathan to try out and see if it reduces his CPU usage. If it does we can consider if this API would be worth it.

> I'm not sure how this could be optimized away without compromising the UX. I'm wondering if there's a way to get a mousemove coalesced to once-per-animation-frame. Seems to be a really common case for UIs?

Here's the try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=453a17093a29668ec1f2885bbfafc71294062c22 Here's the win10 x64 opt build from that try push: https://queue.taskcluster.net/v1/task/X23T5tYeTLWF8NKMcYNSTg/runs/0/artifacts/public/build/target.zip Jonathan, can you try this build and see if the CPU usage is any better? Please record another profile using this build so we can see what else we're spending CPU cycles on. Thanks!

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #15) > Here's the try push: > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=453a17093a29668ec1f2885bbfafc71294062c22 > > Here's the win10 x64 opt build from that try push: > https://queue.taskcluster.net/v1/task/X23T5tYeTLWF8NKMcYNSTg/runs/0/ > artifacts/public/build/target.zip > > Jonathan, can you try this build and see if the CPU usage is any better? > Please record another profile using this build so we can see what else we're > spending CPU cycles on. Thanks! I ran the build target that you linked and the CPU usage is a bit higher than before but not outside a measurement error. I ran a new profile documenting the behavior here. I didn't have time to do another screen capture but can do so if needed. https://perfht.ml/2DkxRx1 Thanks for your ongoing efforts to squash this bug. I am happy to provide whatever additional testing data is required.

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #14) > > I'm not sure how this could be optimized away without compromising the UX. > > I'm wondering if there's a way to get a mousemove coalesced to > once-per-animation-frame. Seems to be a really common case for UIs? We had mouse move coalescing enabled in bug 1403743.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9) > Another small chunk of time (per the profile) is spent dispatching a pointer > event from the mouse event. Presumably that's something we can optimize away > if we know there are no pointermove listeners? We need pointermove to trigger other events (e.g. pointerleave / pointerout) in EventStateManager. We had some optimizations in EventListenerManager when there are no listeners on the current target.