947617 - Clock app consuming too much power

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Clock, defect, P1)

Description

[Dave Huseby [:huseby]]

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.

Comment 1

[Dave Huseby [:huseby]]

Attachment: fxos_clock_app_30s.png

screen shot of FxOS nexus s 30 second data run.

Comment 2

[Dave Huseby [:huseby]]

Attachment: android_clock_app_30s.png

screen shot of android nexus s 30 seconds data run.

Comment 3

[Dave Huseby [:huseby]]

Attachment: fxos_hamachi_clock_app_30s.png

screen shot of fxos hamachi 30 second data run.

Comment 4

[Dave Huseby [:huseby]]

Attachment: FxOS Nexus S Measurement Data

the raw data measured during the FxOS Nexus S tests.

Comment 5

[Dave Huseby [:huseby]]

Attachment: Android Nexus S Measurement Data

raw data measured during the Android Nexus S tests.

Comment 6

[Dave Huseby [:huseby]]

Attachment: FxOS Hamachi Measurement Data

raw data measured during FxOS Hamachi tests

Comment 7

[Jon Hylands [:jhylands]]

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.

Comment 8

[Jon Hylands [:jhylands]]

Attachment: Before Fix

This shows the ammeter readings, before the fix.

Comment 9

[Jon Hylands [:jhylands]]

Attachment: After Fix

This shows the ammeter readings, after the fix was applied.

Comment 10

[Jon Hylands [:jhylands]]

Attachment: Pull Request for fix

See before & after pic attachments for power impact

Comment 11

[Marcus Cavanaugh [:mcav]]

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.

Comment 12

[Jon Hylands [:jhylands]]

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.

Comment 13

[Marcus Cavanaugh [:mcav]]

Landed:

https://github.com/mozilla-b2g/gaia/commit/7e1c255c20b64d09ef0e021b8b9d7377840d4061

Comment 14

[Marcus Cavanaugh [:mcav]]

Reverted due to an unexpected unit test failure; landing again momentarily after Travis passes.

Comment 15

[Marcus Cavanaugh [:mcav]]

And we're back, landed in master:

https://github.com/mozilla-b2g/gaia/commit/bad5658f1c678191e21984d3217a4ad2bfad3c94