Partial updates in onUpdate

Hi guys,

yesterday I tried to optimize my watch face in a way that I wanted to only draw changed portions of the screen in onUpdate. This works fine in the simulator but on a real watch it fails because of the transition animations when pressing up/down key. The problem is as follows:

for every block on the watch face (date, time, battery, activity) I have a member variable storing the last drawn value. When onUpdate is called I check whether the value changed. In case it didn't I simply skip repainting it (normally I would clear with background color and draw the value again). When the transition takes place from a widget back to the watch face in the first transition step all values are painted fine, but the next transition step does not repaint most of the values as they did not change. Unfortunately, as the screen moves, the first draw happens partially outside of the screen and thus those values need to be repainted when they scroll into view. So my concept seems not to work. Is there a better way to achieve this or is onUpdate always meant to redraw the complete screen? Is there a way to come to know when a transition finishes? That way I could redraw the screen after the transition and then update only changed data?

Thanks!

Bye

Former Member over 7 years ago

You've made a valiant effort, and this is a great thing to think about, but unfortunately the system does not have the proper handling to allow this for the exact reasons you have noticed. If the system had a way to let the application know that it has altered the origin due to a transition or (an issue you may not have noticed) obscured part of the screen with a notification, then the could be done, and would probably save some power.

For now, you should assume that everything on the display should always be updated when onUpdate is called in a Watchface because it isn't possible to detect the times when it does not need to be. We have discussed the requirements to allow this from watchfaces, and may be able to provide the necessary information in a future update to the API.

Talkabout over 7 years ago

Thank you for confirming this. The reason I asked was because I have noticed that my watchface needs more time to draw every minute and that causes the transition from one minute to another to be stuttering. But ok, if there is no way to integrate this I'll have to wait.

An idea how this could be implemented is to have 2 methods on a view like

function onTransitionStart(transitionType); // called before onShow/onHide to indicate transition has started

function onTransitionEnd(transitionType); // called after onShow/onHide to indicate transition has finished

This would allow to at least have the information when my view (watchface, app, widget, datafield) moves into the right origin. Not sure if this would solve all problems but at least the ones I have noticed so far.

Thanks!

Bye

travis.vitek over 7 years ago

The reason I asked was because I have noticed that my watchface needs more time to draw every minute

If this is true, then it seems that you've got some sort of problem. Most watch faces would take about the same time to render every minute (they draw the same number of primitives during the 3rd second of every minute).

Talkabout over 7 years ago

Sorry for the confusion! I meant that the drawing that occurs every minute takes much longer than the drawing in onPartialUpdate, which is obvious :) But I wanted to somehow optimize it so the difference is not that huge. So I don't think there is a general issue :)

Bye

travis.vitek over 7 years ago

Oh, sorry about misinterpreting you... Maybe the BufferedBitmap stuff to could be used to reduce the costs? You might be able to overwrite the stuff in the buffered bitmap as needed, and then just draw the things that change frequently directly to the screen.

Travis

Talkabout over 7 years ago

I have not dived into BufferedBitmaps as of now but I will consider this as an option, thanks!

Bye

Talkabout over 7 years ago

Hi,

I have now integrated a buffered bitmap into my watch face that helped me to skip calculations that are not needed.

One thing I noticed still confuses me: when I navigate from my watch face to any other widget the transition is smooth, but when I navigate back to the watchface the transition kind of jumps and completes 1 or 2 transition steps. What is the difference in these 2 transitions, because in my case I am not doing any other calculation while watchface is going to be shown.

Thanks!

Bye

Former Member over 7 years ago

When you leave the watch face, the device just shifts the pixels out of the buffer as it slides the new screen in, and does not re-render your face. When your watchface is coming in, each render contains new pixels from your app, so the onUpdate() method has to be called to render them.

Talkabout over 7 years ago

Hi Brian,

thanks for the explanation!

Would it not be more resource friendly to render the complete watch face first time, then slide it in and at the end execute "onUpdate" again? The animation takes not more than 1 second, I don't think anybody would even realize that it was not rendered multiple times :)

Bye

Former Member over 7 years ago

It depends on what resource you are talking about. It would be friendlier to the processor resource, but significantly less friendly to the RAM resource. It would require an offscreen buffer the size of the entire screen. On the Fenix 5, for example, this buffer would be 56.25KB. Our devices definitely don't have that type of space to spare for an animation buffer that only sticks around for less than a second. If we could afford to throw that kind of memory around, we could probably give you more than 96KB for your watchface. ;)