Persistence of the Dc content between calls to onUpdate()

Anyway, I think my point is it's possible to imagine that things could be improved for newer devices, while keeping backwards compatibility for old devices.

Whether Garmin is willing to do it is another story.

If you follow the Garmin guidance for any app type and always redraw the whole screen when onUpdate is called, nothing needs to change.  That handles a cleared/uncleared dc as well as a toast that covered part of the screen.

On MIP devices with onPartialUpdate, that can be used to update part of the screen in low power mode for a watch face.

jim_m_58 said:

If you follow the Garmin guidance for any app type and always redraw the whole screen when onUpdate is called, nothing needs to change.  That handles a cleared/uncleared dc as well as a toast that covered part of the screen.

On MIP devices with onPartialUpdate, that can be used to update part of the screen in low power mode for a watch face.

Ppl aren't asking for a change to onUpdate() behavior because they don't understand the current behavior or because they're too lazy to update the whole screen every time (it's just code, and it's actually easier to write code that updates the entire screen unconditionally). They're asking for a change to onUpdate() because they want to optimize battery life.

That's why this comes up all the time - devs are trying to optimize battery life by not redrawing the whole screen on every onUpdate(). Yes, the reason they might feel free to do so initially is because they don't understand the current behavior. But that's not the purpose of doing so. Once the current behavior is explained to them, they often make a similar feature request to OP, as you noted.

Ever notice how one of the main complaints about CIQ watch faces is that they're power hungry? Every notice that when ppl complain about battery life with a new firmware update, the first advice they get is to uninstall CIQ apps? Yeah, that's why every dev wants to optimize energy usage.

Your response that things are just fine the way they are (as long as you write your code properly) does not even address the battery life concern that drives developers to want to only update part of the screen during onUpdate(). May as well just say "battery life isn't important".

FlowState said:

They're asking for a change to onUpdate() because they want to optimize battery life.

Even if you change only one line in onUpdate, the battery impact is the same as the entire screen is redrawn by the FW, unlike with onPartialUpdate where only part is redrawn..

And again, there are the toasts.

jim_m_58 said:

And again, there are the toasts.

You say that every single time, but if you use your imagination, any proposed scheme which informs the dev that the screen has been cleared could also inform the user that part of the screen has been covered by a notification (or anything else.) The API (and devs) could treat the 2 situations identically, given that notifications are gonna be a lot rarer than screen clearings (in the case when a device does clear the screen before each update.)

jim_m_58 said:

Even if you change only one line in onUpdate, the battery impact is the same as the entire screen is redrawn by the FW, unlike with onPartialUpdate where only part is redrawn..

Is the battery impact identical though? It seems there are two things to consider here:

1) the app code which needs to determine what to draw, and makes the appropriate dc calls to ask the firmware to draw it

2) the firmware code which redraws the entire screen (as you said), since devs can't set a clipping region for onUpdate()

I think that obviously devs know they can't control 2), but they are trying to optimize 1). Are you claiming that whatever code needs to run in step 1 is free (or negligible)? Even if you use a BufferedBitmap, the call to draw the BufferedBitmap might be expensive.

But let's use our imaginations even harder.

Imagine that Garmin implements some kind of flag which tells onUpdate() "it's ok to just update part of the screen, as the screen wasn't cleared and the existing contents haven't been covered / changed by something like a notification". In the case when this flag is true, Garmin could also allow the dev to use setClip() to set a clipping region for onUpdate(), so the firmware could redraw only part of the screen.

Also, I wlll note that for device apps, widgets and data fields, onUpdate() does not redraw the entire screen / dc. (I know you were referring to watchfaces and I know this is the primary app type where battery life is a concern.) When devs fail to update the entire screen in onUpdate(), they have often noticed that things which were previously drawn are left behind.

I only bring this up because whatever changes are made to onUpdate() could (and should) apply to all app types, not just watchfaces.

Ofc none of this is going to happen, but we can always dream.

Maybe you should try a few things and report back

jim_m_58 said:

Even if you change only one line in onUpdate, the battery impact is the same as the entire screen is redrawn by the FW, unlike with onPartialUpdate where only part is redrawn..

jim_m_58 said:

Maybe you should try a few things and report back

All right, so if you don't think it would save any battery at all, maybe you should have just said that in the first place.

Wonder why people keeping asking for this change though, if everyone agrees that there's no possible battery life gains. Again, it actually makes the code more complex if onUpdate() only draws what's changed since the last time, instead of redrawing the entire screen. So ppl aren't asking for this change to make their lives easier.

On the contrary, everyone who has asked for this said that they're trying to make their code more efficient (wrt battery life). I noticed that when Garmin has replied to these bug reports, they never said that the proposed change would be useless since there's no possible battery gains (which is basically what you said). If they said that (and devs agreed), then it stands to reason that devs would stop asking for this.

I also noticed that one on of the bug reports, you said:

Have you looked at using buffered bitmaps to speed up your draws?

It's interesting you should say that, since that seems to be an admission that the code is in onUpdate() which asks the firmware to draw stuff could be slower or faster depending on how it's done.

IOW, the battery impact would not be the same regardless of what code is in onUpdate(). You said it yourself.

Thought experiment: is the energy used by 10 dc.draw() calls in onUpdate() the same as the energy used for 1 dc.draw() call? (Regardless of whether the firmware redraws the entire screen or not?)

I am far from a CIQ watchface expert (I've never developed one), so I'll defer to your expertise. But it would be nice if you had a better argument than "trust me bro".

And again, even if it were true that there could be no possible battery gains for watchfaces (which I highly doubt but I could be wrong), the same could not be said for device apps and data fields.

Again, try it yourself and report back.