Dumb newbie question about watch face API

in a watchface, onUpdate() is called for you on a regular basis - at most times, once a minute. After a gesture, it will be called every second for about 10 seconds. onEnterSleep() and onExitSleep() are called in your watchface for the two modes. (enter, onUpdate is called once a minute, exit, every second). The name "sleep" is that it's in the 1min update.

With this, you can display seconds between the call to onExitSleep and onEnterSleep.

onPartialUpdate() get's called every second all the time, on watches that support that (fenix 5 and newer). There, you have to be careful about how much you do during the call. There's a limit of an average of 30ms each call. If you exceed that, onPartialUpdate stops being called (it's about the battery). But using that you can do things like show seconds all the time. The Analog sample is a bit more complex than a digial WF, in that yes, it has to use a buffered bitmap and display the part of the screen as the second hand moves, but it uses clip regions, so that the amount the the screen updated is as small as possible.

Here's a Thread with a very simple 1hz digital WF that will show the very basics of 1hz

Jim's pretty much covered this one. I just wanted to mention that onUpdate() may also get called several times a second during the time when the device is transitioning to the face from an adjacent widget. This is something to keep in mind because if you have a particularly complex onUpdate() method, it may reduce the quality of this screen animation when using your face.

jim_m_58 Thanks. There's a lot of complaints about battery life on this forum -- including some from me -- so I suspect it's necessary to be very careful indeed to minimize the amount of work done in a once-per-second update cycle. You say of the Analog sample "...so that the amount the the screen updated is as small as possible" Fair enough, but it seems to me that drawing the second-hand (in that sample) could still be pretty inefficient. The clipping region will be up to a quarter of the total display area, I think; and even though clipping might prevent the work of updating the display, all the math involved in drawing the complete screen is still carried out (in that sample), just not drawn on the actual hardware. I'm not convinced that clipping really takes that much load off the CPU.

I honestly have no feel at all for how significant these factors are. Given how much people complain about how 3rd-part watch faces are killing their battery life, it seems to me that a developer inexperienced with this platform (e.g., me) could easily get into trouble.

Do you have any feel for how much something like drawing a second hand might impact battery life? I guess it would be easy enough to find out, by hacking the Analog sample to produce a version without a second hand, and running it a few days (I just started that). But can the relevant information be extracted from the emulator somehow?

Sorry -- I'm sure these topics must have been discussed in the past.

Best wishes
Kevin

The battery on which watch? It seems that some have having battery issues on the va3, but it could be with the FW. I've not checked lately, but for example, there was a bug at one time on a watch where onUpdate() was being called all the time at 1sec. Doing a full onUpdate every second will have an impact.

But onPartialUpdate is very limited in what it can do every second, so has minor battery impact.

jim_m_58 As it happens I have a VA3, and I struggle to get more than two days relatively light use from the watch before the battery packs up. Some people are reporting < 24 hours. A lot of people are blaming 3rd-party watch faces for this, but I really have no idea how careful a developer has to be.

Do you have any feel for the amount of battery energy used by maintaining a watch face, compared to all the other stuff the these units do behind the scenes? I was looking at the "Analog" sample and it seemed that even in that simple examples there were things that could be done to reduce CPU cycles, if you really had to. For example, there are repeated calculations of parameters like "width/2" that could just be cached. But if maintaining a watch face is only ever going to account for a small fraction of the CPU load, I guess it's not worth fighting to save every CPU cycle.

I have a va3 and I've been getting reasonable battery (with GPS every day). The thing about the device forums, you often see the people with a problem, and the the folks that don't have a problem, don't post. Have you tried a hard boot? Just press the button (15-20 seconds) until the watch turns itself off, then turn it back on

The Analog Sample does 1hz, so a simple way to reduce cycles, is turn of 1hz. Also with 1hz, they can be a bit higher impact for analog than digital, due to the area of the screen that gets updated.

I agree -- there could be a million people who have no problem with their devices at all, who never post anything. That's the nature of forums, I guess. I have to reset my watch every time I charge it, else the battery drops about 5% per hour. I'm pretty sure that's a bug, but it's not a showstopper -- resetting only takes a few seconds. But even then I only get two days' use, with one hour of GPS a day. That's with Bluetooth on, if that makes any difference.

Concerning the watch faces -- I've noticed that some of the built-in faces that update every second do it in ways that don't require much, if any, of the screen to be redrawn. One, for example, has a sort-of ring around the edge of the face that gets added to every second, until there is a complete circle. That's quite clever, because there is no need to redraw anything when the ring is extended. I guess an analog seconds indicator will require less effort to update than a second hand.

I'm currently running on my VA3 a version of the Analog sample app that has all the 1Hz stuff removed, so I can see what effect the second hand has, if any.

Native watchfaces aren't CIQ. You not get to their power level in CIQ, but can get close.

OK. Nevertheless, with my modified "Analog" watch face -- with no IHz stuff, and tidied up to eliminate repeated calculations etc -- I'm seeing the lower battery drain I have so far recorded. Over the last 12 hours it's been about 0.5% per hour. Of course, that's 12 hours of idleness -- I'm not sure yet what will happen when I start doing stuff.

I suppose to some extent users have to accept that, if they want fancy, dynamic, watch faces, they have to take a bit of a hit on battery life. At present, however, I have no idea how big that hit is likely to be.

It occurs to me, for example, that in a "real" analog watch, the minute hand moves along with the second hand; it doesn't just flip from tick mark to tick mark. All the Garmin watches faces that I've seen with a second hand -- including the built-in ones -- look "wrong" to me, because the minute hand just clicks from one position to the next. But doing it this way avoids the necessity to redraw the whole screen every second.