Clock app consuming too much power

RESOLVED FIXED in 1.4 S2 (28feb)

Status

Firefox OS
Gaia::Clock
P1
normal
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: huseby, Assigned: jhylands)

Tracking

({perf, power})

unspecified
1.4 S2 (28feb)
ARM
Gonk (Firefox OS)
perf, power

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [c=power p=2 s= u=])

Attachments

(9 attachments)

(Reporter)

Description

5 years ago
Using a yoctopuce ammeter and mozilla battery harnesses for the nexus s and hamachi devices, I measured the launch and idle power consumption of the clock app.  It appears that there is ample opportunity to optimize the app for lower power consumption.

For the launch test, I started the ammeter, touched the clock icon to launch it and then stopped the ammeter after 10 seconds.  I then killed the clock app and repeated the test.

For the idle test, I started the clock app, let it run for 5 seconds, then ran the ammeter for 30 seconds.  I then killed the clock app and repeated.

I did this on a Nexus S running FxOS 1.3, a Nexus S running Android 2.3.4, and a Hamachi running FxOS 1.3.

The raw data is attached to this bug.  Here are the mean values for each test:

App Launch:
FxOS Nexus S:     228 mA
Android Nexus S:  198 mA
FxOS Hamachi:     143 mA

App Idle:
FxOS Nexus S:     175 mA
Android Nexus S:  147 mA
FxOS Hamachi:     128 mA

This might be a little hardware dependent in that the Nexus S's clock hardware just consumes more data.  But if you compare the FxOS and Android numbers on the Nexus S, we should at least be 5%.  For the app launch, we're 15% more, and for the idle, we're 19% more.
(Reporter)

Comment 1

5 years ago
Created attachment 8344203 [details]
fxos_clock_app_30s.png

screen shot of FxOS nexus s 30 second data run.
(Reporter)

Comment 2

5 years ago
Created attachment 8344205 [details]
android_clock_app_30s.png

screen shot of android nexus s 30 seconds data run.
(Reporter)

Comment 3

5 years ago
Created attachment 8344206 [details]
fxos_hamachi_clock_app_30s.png

screen shot of fxos hamachi 30 second data run.
(Reporter)

Comment 4

5 years ago
Created attachment 8344207 [details]
FxOS Nexus S Measurement Data

the raw data measured during the FxOS Nexus S tests.
(Reporter)

Comment 5

5 years ago
Created attachment 8344208 [details]
Android Nexus S Measurement Data

raw data measured during the Android Nexus S tests.
(Reporter)

Comment 6

5 years ago
Created attachment 8344209 [details]
FxOS Hamachi Measurement Data

raw data measured during FxOS Hamachi tests
(Assignee)

Comment 7

5 years ago
Although we don't have the ammeter data integrated into the profiler UI yet, it is possible to do manual correlation of the data.

As expected, there is a fairly big jump in both CPU and power usage for ~50ms every second, but there is another jump in both about 300-400 ms before each second count, and the same code is being called from an actual Timer tick (nsDisplayList::PaitRoot takes most of the time in each case).

Since the actual clock GUI is only updating once per second, we should be able to almost cut the extra power usage in half by eliminating this second refresh. Turning on the "Flash repainted area" option, its pretty clear that the clock face is updating twice a second, even though it is only changing once. Perhaps it is redrawing the entire clock face without the second hand, and then redrawing again with the second hand in the new spot.
(Assignee)

Updated

5 years ago
Assignee: nobody → jhylands

Updated

5 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 8

5 years ago
Created attachment 8378439 [details]
Before Fix

This shows the ammeter readings, before the fix.
(Assignee)

Comment 9

5 years ago
Created attachment 8378441 [details]
After Fix

This shows the ammeter readings, after the fix was applied.
(Assignee)

Comment 10

5 years ago
Created attachment 8378442 [details]
Pull Request for fix

See before & after pic attachments for power impact
Attachment #8378442 - Flags: review?(m)
(Assignee)

Updated

5 years ago
Whiteboard: [c=power p=1 s= u=] → [c=power p=2 s= u=]
Comment on attachment 8378442 [details]
Pull Request for fix

Thanks! This looks good, but could you explain what the translateZ(1px) does, and why it addresses the problem? In the past I've seen translateZ(0) used to trick browsers into GPU rendering; is that what's going on here or is this something different?

Ideally it'd be good to have a comment in the CSS to explain why, otherwise r+ from me.
Attachment #8378442 - Flags: review?(m) → review+
(Assignee)

Comment 12

5 years ago
Yes, this invokes the GPU, and thus cuts way down on both CPU and power usage. The GPU is apparently much smarter about drawing stuff multiple times (which was happening before), so it ends up doing much less work.
Landed:

https://github.com/mozilla-b2g/gaia/commit/7e1c255c20b64d09ef0e021b8b9d7377840d4061
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Reverted due to an unexpected unit test failure; landing again momentarily after Travis passes.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
And we're back, landed in master:

https://github.com/mozilla-b2g/gaia/commit/bad5658f1c678191e21984d3217a4ad2bfad3c94
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Updated

4 years ago
Target Milestone: --- → 1.4 S2 (28feb)

Updated

4 years ago
Keywords: perf
You need to log in before you can comment on or make changes to this bug.