css animated throbber causes heavy cpu load

RESOLVED FIXED in Firefox 33

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jrmuizel, Assigned: jaws)

Tracking

({perf})

unspecified
Firefox 35
Points:
1
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(firefox33 fixed, firefox34+ fixed, firefox35+ fixed)

Details

We have much higher cpu load from this animation with limited benefit. This animation seems to cause high cpu load even when the throbber is not visible.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #0)
> We have much higher cpu load from this animation with limited benefit. This
> animation seems to cause high cpu load even when the throbber is not visible.

This would be bug 962594, which we worked around in bug 1016942. So this shouldn't be happening anymore...
Jeff, is comment 1 wrong?
Flags: needinfo?(jmuizelaar)
(In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #2)
> Jeff, is comment 1 wrong?

Yes. I still have high load when non-visible tabs have a spinning throbber. The load is also especially high when the tabs are still visible? Is there a performance comparison somewhere to the previous animated png throbber? I see 39% Nightly cpu usage and 46% WindowServer usage with a visible throbber. Is this expected?
Flags: needinfo?(jmuizelaar)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> (In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #2)
> > Jeff, is comment 1 wrong?
> 
> Yes. I still have high load when non-visible tabs have a spinning throbber.

You mean tabs that are scrolled off-screen? Would the png throbber stop animating and straining the CPU in that case?

> The load is also especially high when the tabs are still visible? Is there a
> performance comparison somewhere to the previous animated png throbber? I
> see 39% Nightly cpu usage and 46% WindowServer usage with a visible
> throbber. Is this expected?

That's to some extent expected, as the png throbber has a lower frame rate. The CSS animation is expected to be smoother. Another expectation is that off-main-thread animations will alleviate the performance impact.
(In reply to Dão Gottwald [:dao] from comment #4)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> > (In reply to :Gavin Sharp [email: gavin@gavinsharp.com] from comment #2)
> > > Jeff, is comment 1 wrong?
> > 
> > Yes. I still have high load when non-visible tabs have a spinning throbber.
> 
> You mean tabs that are scrolled off-screen? Would the png throbber stop
> animating and straining the CPU in that case?

I'm not sure. I never noticed cpu load from the png throbbers though.

> > The load is also especially high when the tabs are still visible? Is there a
> > performance comparison somewhere to the previous animated png throbber? I
> > see 39% Nightly cpu usage and 46% WindowServer usage with a visible
> > throbber. Is this expected?
> 
> That's to some extent expected, as the png throbber has a lower frame rate.
> The CSS animation is expected to be smoother. Another expectation is that
> off-main-thread animations will alleviate the performance impact.

We don't have off-main-thread animations on right now. I expect it might be worth waiting till then before enabling the css-animation.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)
> We don't have off-main-thread animations on right now. I expect it might be
> worth waiting till then before enabling the css-animation.

We've been backing out the CSS throbber from Firefox 32 and 33 and we should probably keep doing that until off-main-thread animations are enabled.
[Tracking Requested - why for this release]: see comment 6
Blocks: 759252
Component: Toolbars and Customization → Theme
Keywords: perf
OS: Mac OS X → All
Hardware: x86 → All
(In reply to Dão Gottwald [:dao] from comment #6)
> We've been backing out the CSS throbber from Firefox 32 and 33 and we should
> probably keep doing that until off-main-thread animations are enabled.

+1 Can we back out the CSS throbber altogether and reland the it after OMTC animations land?
Flags: needinfo?(dao)
Yeah, I agree, we should just back out. It doesn't appear that OMTC will be enabled on Windows Nightly for quite a few releases still (please correct me if I'm wrong).
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #9)
> Yeah, I agree, we should just back out. It doesn't appear that OMTC will be
> enabled on Windows Nightly for quite a few releases still (please correct me
> if I'm wrong).

This needs Off Main Thread Animations not just OMTC. OMTC will hopefully be in the upcoming release.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #10)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #9)
> > Yeah, I agree, we should just back out. It doesn't appear that OMTC will be
> > enabled on Windows Nightly for quite a few releases still (please correct me
> > if I'm wrong).
> 
> This needs Off Main Thread Animations not just OMTC. OMTC will hopefully be
> in the upcoming release.

Sorry and thanks for the clarification.
https://hg.mozilla.org/mozilla-central/rev/4af29b25a7bf
Assignee: nobody → jaws
Target Milestone: --- → Firefox 35
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Iteration: --- → 35.3
Points: --- → 1
Flags: qe-verify?
Flags: firefox-backlog+
jaws - 34 is marked as affected. Can you please submit an Aurora uplift request?
Flags: needinfo?(jaws)
Erm, rather, can you back this out of 34 as I see it has been backed out of 32, 33, and 35?
This was verified in bug 1016434.
Flags: qe-verify?
Flags: qe-verify-
Flags: needinfo?(jaws)
You need to log in before you can comment on or make changes to this bug.