How do I work out what to redraw in onUpdate()?

Hi. I'm sure this question must have been raised before, but I can't find an answer.

In the pre-OLED days, I think I understood how onUpdate()/onPartialUpdate() were supposed to work. With the Venu 2 (and, I guess, other OLED devices) things seem to be different. When the watch is woken by a button-press or gesture, onUpdate() gets called repeatedly -- perhaps ten(?) times -- at one-second intervals. Then the watch goes back to sleep, and it doesn't get called again until the next minute.

Meanwhile, with the OLED watches, it looks as if onPartialUpdate() is never called at all.

So -- suppose I want to update a small area of the screen when the watch is awake -- perhaps a seconds display. I don't see any alternative to drawing the entire screen every time onUpdate() is called. There doesn't seem to be any way to work out what actually needs to be updated. This seems like a waste of battery, erasing and redrawing the entire screen every second, when only a tiny region has changed.

And what happened to onPartialUpdate()? It is still called on the Vivoactive 3 (maybe others as well), but is never called on the Venu 2.

So, in short -- with the OLED watches, how do I update a small screen area only at 1Hz?

Have I missed something?

Top Replies

All Replies

0 FlowState 13 days ago in reply to jim_m_58

jim_m_58 said:
You don't see the clear/no clear difference in the sim, and never have.

If Garmin cared to notice that this topic comes up on a regular basis, they would simply change the sim so that the screen is cleared before onUpdate() is called. Clearly it makes more sense to model the worst-case behavior of onUpdate() in the sim as opposed to the best-case behavior, since you want handle the former and not just the latter. So there’s no need to behave just like each and every device in terms of whether the screen is cleared or not, or to emulate stuff like notifications. Just clear the screen before onUpdate() and devs will be forced to do the right thing: redraw everything in onUpdate().

I know for a fact that devs have had screen update bugs in apps deployed to the store bc they trusted the behavior of the sim. “My app works great in the sim and on my device, but my users complain that the screen doesn’t update properly on their device!”

Before you say that “the simulator is not an emulator” and “they should’ve read 9 years of forum posts first”, the fact that the “community” knows all about this and that every dev will eventually discover this is not my point. My point is that this kind of thing reflects badly on Garmin (fair or not, Garmin will be judged by the quality of the apps in its store, at least by people who even use apps), and it’s entirely within their power to do some of the little things to improve this situation.

Or it could be that Garmin (as an organization, not the individual employees) doesn’t really care about CIQ. Yeah I get it, it’s a big company and they have priorities, resource constraints, internal politics, deadlines, etc.

0 Jacquers 13 days ago in reply to FlowState

Agreed, it would be nice if the sim behaved as close to the watch as possible, more like an emulator. Even the timings of the profiler can be misleading because it will give better / worse numbers depending on the specs of your pc. But it's still useful as a guideline to find bottlenecks.

If the actual device does a clear, then is it wasteful for performance to do it in the code? Or would the compiler maybe optimize this?

0 Jacquers 1 day ago in reply to Jacquers

Just FYI, I was curious, so I tried it on a Venu 2 (physical device) and also no need to do a dc.Clear() on there. Haven't seen any overlapping text from not clearing or odd artifacts so far, even with notifications showing. I've only tried high power mode, so can't say for certain if low power mode will also behave this way, but I assume it would.

Not doing the clear in the sim indicates some performance improvement, but I don't know how much it translates to on an actual device. I suppose I could try to do some logging to see.