High CPU load when activity animation bar appears

RESOLVED WONTFIX

Status

defect
RESOLVED WONTFIX
5 years ago
4 years ago

People

(Reporter: zrzut01, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

5 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

1. Start outgoing call or answer incoming call.
2. Press Home button to get into Home screen.
3. After a while the animation on the top of a screen (the blue line moving from the centre to sides) appears.

OR

Because of bug 1104320 the animation will stay on the screen after turn off an alarm of Alarm Clock.


Actual results:

When the animation is visible on the screen the CPU load is between 79-85%.


Expected results:

The animation should generate CPU load below few percents.
Reporter

Comment 1

5 years ago
Found on:

Alcatel One Touch Fire production (got from T-mobile Poland)
B2G version: 2.2.0.0-prerelease master
Platform version: 36.0a1
Build Identifier: 20141122180308
Git commit info: 2014-11-22 08:56:01 d1a128fa
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Reporter

Comment 2

5 years ago
Please turn off the animation immediately because it looks like the cause of serious performance bottleneck during every event (incoming SMS, incoming/outgoing call and etc.)
Reporter

Comment 3

5 years ago
As I guess you know who can take a look on the issue?
Flags: needinfo?(etienne)
Hey Kevin, I know you tweaked the app chrome loading bar to be less CPU intensive, any tips on what we should do here?
Flags: needinfo?(etienne) → needinfo?(kgrandon)
Are we supposed to be playing a continuous animation here?

If it's causing major performance problems it seems like we should just axe the animation for now, and go to a solid line while we follow-up with UX.

Regarding the progress bar, I had split that up into 15 steps over 1.5s, so no update faster than 0.1s. If this animation is intended, I don't think it would look good with those steps, so we should rethink the animation in the first place, or the display of it.
Flags: needinfo?(kgrandon)
I think the animation is pretty important. It's how you distinguish "I have unread notifications" from "I have an ongoing phone call".

Rob could we change the color of the indicator instead?
Or maybe make the animation less intensive? (I'm thinking one "pulse" every second or so instead of a continuous animation).
Flags: needinfo?(rmacdonald)
Reporter

Comment 7

5 years ago
Again, could you just remove/disable the animation or at least replace it with static bar but different colour (i.e. red) till you find the final solution? 

Thanks in advance ...

Comment 8

5 years ago
It's really annoying, when I can't answer call, because of animation...
I think any workaroud could be good (mac had good ideas), but after two weeks we still have nothing...

Etienne, any updates?
Flags: needinfo?(etienne)
(In reply to Kamil from comment #8)
> Etienne, any updates?

we need UX input first.
Flags: needinfo?(etienne) → needinfo?(firefoxos-ux-bugzilla)

Comment 10

5 years ago
Rob is already flagged so clearing the general UX flag.
Flags: needinfo?(firefoxos-ux-bugzilla)
Apologies for the delays on this one. We need the animation to differentiate an active call from the notifications and to draw attention the call so changing color isn't likely enough in this case. Is there any way we can make the animation less intense? Also NI'ing Eric for additional feedback.
Flags: needinfo?(rmacdonald) → needinfo?(epang)
(In reply to Rob MacDonald [:robmac] from comment #11)
> Apologies for the delays on this one. We need the animation to differentiate
> an active call from the notifications and to draw attention the call so
> changing color isn't likely enough in this case. Is there any way we can
> make the animation less intense? Also NI'ing Eric for additional feedback.

Based on Etienne's comment 6 if reducing the pulse to every second will fix this problem I think we should give it a try.  I agree with Rob that the animation is an important indicator.  It shows something is currently happening and requires the users attention.
Flags: needinfo?(epang)
Reporter

Comment 13

4 years ago
The situation is same on Flame, tested on:

TCT Flame (got from Foxtrot Programme)
B2G version: 3.0.0.0-prerelease master
Platform version: 40.0a1
Build Identifier: 20150410160204
Git commit info: 2015-04-10 14:38:19 3c68964c
Mass update: Resolve wontfix all issues with legacy homescreens.

As of 2.6 we have a new homescreen and having these issues open is confusing. All issues will block bug 1231115 so we can use that to re-visit any of these if needed.
Blocks: 1231115
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.