How taxing are partial updates to battery usage?

When the watchface leaves low power mode, it's only for 10 seconds after a gesture, so it really doesn't happen that often. If you are thinking about only updating poart of the screen, that's actually really tricky with normal onUpdate, as with layouts the screen gets cleared each time (View.onUpdate() and you can possibly run into things were a popup/toast was covering part of the screen. I say possibly because it's something I don't do and I'm basing it what I recall reading about. The main usage on onExitSleep is to know when you are getting calls to onUpdate every second so you can display more info like the seconds.

Now if you are talking about using onPartialUpdate(), that's a different thing where on supported watches, onPartialUpdate is called every second, and you can updated a liminted part of the screen, with the most common example being showing "seconds all the time", but is also used for displaying the HR as it updates (every few seconds).

The key there is the power budget. With onPartialUpdate if you exceed an avg of 30ms for the calls over a minutes, onPartialUpdate stops being called and the WF gets notified by way of a delegate.

Here's a thread that goes into onPartialUpdate/1hz that started when it first came out:
https://forums.garmin.com/forum/developers/connect-iq/158133-?376929=

Now if you are talking about using onPartialUpdate(), that's a different thing where on supported watches, onPartialUpdate is called every second, and you can updated a liminted part of the screen, with the most common example being showing "seconds all the time", but is also used for displaying the HR as it updates (every few seconds).]

Indeed, I was talking about the actual partial updates, on devices that support them. I'm curious what are other people's experiences are on battery consumption with these, or indeed if Garmin has any info on this, besides not going over the 30ms budget.

So much of this depends on your watchface design. The thread I linked to has some info, but a big one is not just stay under the budget, but to be as far under it as possible. (30ms can be pretty tight based on the design!) Things like a traditional analog with have more of an impact because there's more calculations involved for a second hand than for a digital seconds. and typically a larger clip region. In the sim there is "watchface diagnostics" that let you keep an eye on things. I'm running one right now where the avg is about 15 ms, but the seconds are larger and use a custom font, while one with smaller seconds and a std font has an avg of 9ms. I have another WF where the budget avg is under 3ms. And as far as overall impact, with a number of WF that do 1hz and in over a year, I've seem no problem with the battery.

So, it's not the function itself, but how you use the function that determines the battery impact, and the overall design impacts that. Same for any app in general.

The 30ms can be a bit harsh, but the reason for that is to limit the impact while still allowing the functionality.

Thanks, that's helpful. I'll take a look at those watchface diagnostics, sounds like something useful to debug this.

Do a WF you like without 1hz, and see how it works. Then start adding 1hz stuff, and bear in mind that at times, the battery drain can be a bit nutty based on your specific watch (see the device specific forums). Maybe tweak the UI a bit to help with 1hz, and drill into your onPartialUpdate code (do as little there as possible - and example is the x/y for seconds. You can do that in onUpdate based on HH:MM, and not in onPartialUpdate() and make sure you use the delegate for exceeding the budget and handle things when that does happen.

The vsh1z WF I posed in the 1hz thead shows the handling of of exceeding the budget as well as handling devices without 1hz in the same code.