watch face power optimization questions

I know how to monitor the processing and graphics load while in sleep mode, but how do you figure out how to optimize the code in the active mode when onUpdate() is triggering every second? The sleep mode loading monitor just displays zeroes when in the normal onUpdate() mode, so I don't know how to evaluate different coding styles for power efficiency.

for example, is it more efficient to draw a rectangle with dc.drawLine() and dc.setPenWidth(), or by defining the 4 corners of a polygon and calling dc.fillPoly()? Think of it in the context of analog watch hands, I have to compute the coefficients for x and y for every minute around the watch face, so drawLine() is a lot easier because it only requires the two endpoints instead of 4 corners for fillPoly(). Is there any appreciable difference in power consumption between those two options?

Also, is there any advantage to pre-calculating all 60 x/y co-ordinates and loading that into an array, then just index the array instead of computing the x/y co-ordinates each time on the fly based on the minute hand angle?

Finally, is there any way to get reliable feedback from the watch face simulator on how efficient each approach might be? In the context of the sleep mode power monitor, how would you weight the execution/graphics/display times for power consumption. Are they all equally weighted, so the total time would be the ultimate metric for sleep mode power consumption, or is one of them more dominant in power consumption? Similar question for the active mode onUpdate() code execution question asked earlier, is there anything that monitors and displays that info?

thanks.

jim_m_58 over 3 years ago

Dropping out of low power on a real device will have minimal impact as that only occurs with a gesture and stays that way for 10 seconds.

In low power, onUpdate is only called every minute. with onPartialUpdate being every second, and very restrictive (the 30ms thing you can see in watch face diagnostics).

Amoled/lcd devive have the need for "prevent burn-in" logic. and that you can check for in the sim with the "heat map".

After that, the rule of thumb is to save battery, drawing 10 things is better than drawing 100. That's why a simple watch face would be better for the battery than one with 5 graphs and 10 data field.

5693709 over 3 years ago in reply to jim_m_58

the heat map selection is greyed out in my simulator, how do I access it?

Also, regarding burn-in, if I have a watchface with tick marks for each minute, bars at 5 minute intervals that are written once and never change, is that potentially a problem with burn-in?

And, it sounds like I'll just have to go with trial-and-error regarding the power consumption. I have an app I've written that captures the battery power and time of day it was captured, and then tracks power consumption over time by dividing the battery usage by the elapsed time as it runs. Since I keep the app not running while measuring the watchface, it doesn't contribute at all to the power consumption until I start the app again a few hours later to display the result.

Based on that, my original app was running at about 2.5% per day, and was doing a lot of coordinate calculations in the onUpdate() method. When I rewrote the code to what seemed more efficient and simpler, the consumption went up to 3.2% per day. The one variable in that measurement is I'm not sure the battery discharge curve is linear, I suspect its not, so it may make a difference between the battery dropping from 95% to 90% and say 80% to 75%.

jim_m_58 over 3 years ago in reply to 5693709

You'll only see the heat map with amoled/lcd devices as targets (venu devices)

On MIP devices you don't need to worry about burn-in.

Look into onEnterSleep and onExitSleep as how you can tell if you're in low power mode or not.

5693709 over 3 years ago in reply to jim_m_58

I know when I'm in low power mode because I change the color of the seconds display. To minimize power I have analog hands for hours and minutes, but a numerical display for seconds. That way with setClip() I only update a very tiny part of the screen every second while in sleep, so that processing is very low power. And, it clues me into how much gesture is required to come out of sleep. But, while walking around with my wrist moving I suspect I'll be in normal power mode a fair amount of time, so I'd like to optimize that also.