Buffered Bitmap vs Drawing to Screen from scratch

Is there a power/energy difference between using the buffered bitmap to draw to screen vs. going to the function and drawing to screen. The function essentially sets the color of the text and then draws the text (a four numeral string). It seems from the Analog sample code that the buffered bit map is sent to the watch face every second. So, I don't even see it using the clipping coordinates to be smarter as to when to redraw.... Thanks for any thoughts in advance...

Top Replies

jim_m_58 over 6 years ago +1

In the case of a digital watch face, I've never used a buffered bitmap. I know the x,y, width, height for a clip region, I set that, clear that, and update the seconds (for example).

With an analog…

All Replies

jim_m_58 over 6 years ago

In the case of a digital watch face, I've never used a buffered bitmap. I know the x,y, width, height for a clip region, I set that, clear that, and update the seconds (for example).

With an analog one, things are a bit more complex as you move the second hand, so want to clear the old location and draw in the new location, and if you have a buffered bitmap without the second hand, you just use that and draw the second hand. Much less complex that having to also manage the hour and minute hand and then drawing the second hand.

You always want to do as little as possible in onPartialUpdate. There's a power budget you don't want to exceed (an avg of 30ms per call for a minute).

A BIG impact on this is the number of rows on the display involved. And with multiple clip regions, this might nt be obvious.

Let's say you have a clip region that starts at row 20 and is 20 high, That's 20 rows. But if you add a second one at row 150 that's also 20 high, that's 150 rows. Using "view watch face diagnostics" in the sim, you can get an idea of where you're at, budget wise.

Here's a whole thread about 1hz watchfaces:

https://forums.garmin.com/developer/connect-iq/f/discussion/5156/1hz-watch-faces---q-a/