Acknowledged
2 months ago

Request - specify if WatchUi.View.onUpdate() is required or optional

If onUpdate() calls would allow differentiating between updates that are required and that are optional, it would allow avoiding unnecessary repainting.

For example, if a watch face does not require updating every second (by showing just HH:MM), then 59 repaints every minute in high-power mode go to waste.

On the other hand, if the OS wipes the screen clean for some reason, then onUpdate() obviously must execute.

The request is to change onUpdate to include an extra parameter to specify if the update is optional or not:

onUpdate(dc as Graphics.Dc, required as Boolean) as Void

This would help writing more power-efficient code.

eau_de_vie
  • 1 month ago

    One compromise could be to use a BufferedBitmap, so you can render your image offscreen and only update the parts you need. You won't save the time that system uses to copy the BufferedBitmap to the display, but you will save the time that you would spend drawing parts of the image that haven't changed.

  • 1 month ago

    To add another use case here that would benefit from this change way more.

    I have a watch face for AMOLED models that does a short custom animation upon entering High Power mode.

    The animation is driven by a short-interval timer that issues requestUpdate() on every tick and runs at about 20 fps.

    There are however a lot of back-to-back animation frames that are identical. Think - it fades in some text, pauses and then fades the text out.

    onUpdate() re-painting the same image is clearly wasteful. There is also a lot of them, so the logical thing to do is not to repaint if the content didn't change.

    In the simulator this works fine. On a real VA5 it doesn't.

    For whatever reason the watch erases the screen between onUpdate() calls even if these calls are spaced milliseconds apart. So the repaint is needed on every tick.

    With this approach, knowing if the screen is in tact is the key to making power-efficient custom animations. As the API stands now, it's not possible to do in principle.

    ---

    I should also add that if the Dc class had getPixel() method, it could've been used to test if a known non-black pixel is set or not. A cheap and hacky test for whether the screen is blank. Alas, Dc is write-only.

  • 1 month ago

    Having thought about this a bit more -

    The "required" parameter may be switched from Boolean to "Rectangle or Null" to specify more precisely which part of the screen (if any) needs repainting.

    If it's "null", then the screen is intact since the last onUpdate() call.

    If it's a rectangle, then it can be used to specify full or partial screen repaint, e.g. due to a toaster popup.

  • 2 months ago

    “It's causing CIQ faces to feel sluggish when entering high-power mode, and it's draining batteries.”

    According to “accepted forum wisdom” there’s no possible advantage to only updating part of the display in onUpdate() (even if the API was able to communicate under which circumstances this is possible / permissible.)

  • 2 months ago in reply to flocsy🤠

    This is probably the single biggest issue impacting the CIQ developers right now.  It's causing CIQ faces to feel sluggish when entering high-power mode, and it's draining batteries.  There's a HUGE bug on Epix 2 Pro that paints the screen every single second in low-power mode.  Battery drain is ridiculous for CIQ faces.

    I finally bit the bullet and developed this exact system.  It worked great on my Epix 2 Pro, and I thought I had a breakthrough in responsiveness and battery usage.  The sleep-wakes were super responsive.  And the battery usage was MUCh better.

    But once I rolled it out, users on other devices flooded in with bug reports.  It turns out that some devices clear the screen, making a paint on every call necessary.  So all those customers were getting "black screens" when an unnecessary paint was called.

    I reverted back to a prior version, and here I am now trying to see if I can figure out a new fix.  It was night-and-day better with the fix, but maybe I can only deploy that on my own device (Epix 2 Pro)?

    Here's my thread on this in the forums:
    forums.garmin.com/.../when-woken-onupdate-is-called-6-times-before-onexitsleep-called