Captures dc into BufferedBitmap

Hello!
I propose adding a function into API
var mBufferedBitmap = dc.getClip (x, y, width, height);
Captures the displayed content region and stores it in a BufferedBitmap. This saved region can then be displayed again.
For example, before drawing the second hand, they will save the region where this hand will be drawn. Then, when the hand moves to the next position, redrawing the saved region will restore the original screen. In this way it will not be necessary to redraw with drawLine/fillPolygon etc. the hour and minute hands. This will significantly reduce the energy consumption for redrawing the screen and extend the time from full charge to battery discharge, which will increase the competitive advantage of your products on the market of smart watches.

jim_m_58 over 7 years ago

That would actually cause overhead in apps that don't need it.
To help with battery, you want to stay as far under the 30ms avg as possible in onPartialUpdate. You can see where you are at with "View Watchface Diagnostics" in the sim.

Have you looked at the analog sample in the SDK?

Travis.ConnectIQ over 7 years ago

I'm pretty sure you can do what you want already, you're just thinking about it backward. If you have a buffered bitmap with the hour/minute hands pre-rendered, just blit that to the screen (using setClip as appropriate) and then draw the second hand over the top of that. Right?

jim_m_58 over 7 years ago

That's what I was thinking Travis. I'm pretty sure that's how the analog sample works.

Former Member over 7 years ago

It is true that you can achieve a similar result by pre-rendering your background graphics into a buffered bitmap. This is done by the Analog sample. I know there watchfaces in the store that have used this process also.

There could definitely be cases where the option described by bine8x8 provides a simpler, or more efficient solution. It is a feature that is worth considering.

bine8x8 over 7 years ago

I will explain this idea in more detail.
Currently, to speed up screen output, it is necessary to display it in a separate buffer, taking into account the coordinates relative to the main screen.
The proposed function allows me to immediately display the main screen. If necessary, you can capture only the variable part of the main screen, and then display the desired image on the main screen. When it is necessary to restore an image — to restore only the saved part — there is no need to restore the entire screen — it has not been changed.
Perhaps two preferences for implementing the proposed API function. If you need to save memory resources, you must first determine the palette to be fixed. If speed is required, copy a portion of the screen into a full-color buffered bitmap Without wasting CPU time on analyzing the palette.

ekutter-dnu over 7 years ago

But how is this much different than always doing the initial drawing to an off screen bitmap and copying that to the screen. Then just copying the portions you need later? Is it the memory resources you are worried about, caching the entire screen?

bine8x8 over 7 years ago

Is it the memory resources you are worried about, caching the entire screen?

Not saving memory, but the convenience of rendering and accelerating the development of programs.

For example, I developed this one https://apps.garmin.com/ru-RU/apps/8a76e0bb-0238-4763-a29f-698b0c06bad0
Here, for a smooth display of the seconds marker, I made 4 parts of the screen. In each part there are two arcs - full and percentage. I had to disentangle the coordinates of the center and the area to render a part of the arc.
Having at my disposal the proposed function, I would simply draw these arcs on a clean screen, and then use this function to capture them and use them as needed.
Or even easier - before rendering the second marker, I would capture not a quarter of the screen, but only the marker area. And I would not care about what is there. When the second marker has moved - I would just draw the memorized part in its place and move from the next iteration.