Find out which portion of the screen to redraw

When onUpdate is called you always need to re-draw the entire screen.  On some devices, the screen is even cleared before you see the onUpdate, and you won't see this in the sim.

in watch faces, there is onPartialUpdate() when you can update only part of the screen.

Hi Jim,

yes, I am aware, but this is a big problem for apps where frequent updates need to be made. As we all try to save as much battery as possible, this would greatly improve battery consumption for a lot of apps. Not sure if technically it is that difficult, but I assume that the framework knows what kind of redraw is required (screen cleared, notification covering half of the screen...), why not let the developer utilize this information?

Bye

You know if you update the display 20x a second by way of a timer and WatchUi.requestUpdate(). it's not really updating that fast, as updating the screen could take 100ms or more.  The requests get queued and ignored.

It's always been the rule you need to update the whole screen when onUpdate() is called, and there have been many threads about this, including input from Garmin

Yes Jim, I understand that. But only because something is like it is does not mean it cannot be improved. From my point of view this functionality/information will increase battery life when using apps, so Garmin should be very interested in adding it (or a similar way so developers can decrease battery consumption). I would be very happy if a Garmin developer would join the discussion and explain why from their point of view this is not a good idea or technically not possible.

By the way, do you remember the input given by Garmin at that time?

Updating the screen 20x or even 10x a second, even if it's only part of the screen will have a bad impact on the battery.  I have one app that updates the screen once a second by default, but with an option of extend the battery life by doing nothing more that only updating the screen every 2 seconds.  And it's VERY noticeable.

Let's say your time is in the "minutes" range.  Isn't updating the screen once a second enough?  When you stop, the user can see more detail.  Now what if it goes into the "hours" range.  You'll soon run out of space on the screen with 100ths of a second, unless you make things small (harder to read)

Hi Jim,

yes, I agree, updating the screen as frequently as I do is not optimal, but for a stopwatch I kind of expect that milliseconds are also "moving". I will now integrate a logic that updates only the required clip as frequently as 20x a second and the other part only once a second. This will surely reduce the battery consumption, but it is still not the final goal. Will think what else can be done.

Thanks for your support!

By the way Jim, do you know how the redraw internally deals with pixels that are already in the correct color? Lets say an app does a redraw, but the redraw only changes a few pixels (compared to the previous state). Does the framework really redraw every single pixel on the watch screen or only the pixels that have changed? Because theoretically connectiq knows what color every pixel has, and it wouldn't need to redraw the pixels again that have not changed, right?

Something I'd not done before, but dc.setClip() might be used in an app.  (don't forget to do the dc.clearClip() when needed).  I wasn't sure if it worked with AMOLED devices, but it does in the sim.

Ok, this will look odd, it's by design.  I set the clip region to be the top of the time, and I draw the time with a single drawText.  Notice how the top changes, but the bottom doesn't?  Updating only part of the display...

Now, about the pixels.  Bear in mind that changing a few in the sim could look different than you'll see on a real device.  In the sim, the size of the image is based on the number of pixels on that device, while on the watch, the pixel size depends on the screen size.  So with something with a 454x454 display, you might see the changes in the sim, but it's highly doubtful you'll see a change like that on a real device.

Or are you thinking kind of an animation where you are changing a few with each call?

This still doesn't change the fact that you need to redraw the whole screen when onUpdate() is called.

Hi Jim,

yes, I implemented the logic mentioned above based on "setClip". Basically the most frequent call (20x a second) is only updating the screen area where the timer is running, whereas every second I am updating the complete screen. This seems to work fine on simulator and real device from what I have tested. This is still not the optimum but it should decrease battery consumption. I will think about other options to further optimize in a later stage.