full-screen background image

Rotate is quite ok for drawing the hand.
What I wanted to say is that you might need 60 images each containing the background for each minute.

I still feel it might be doable to restore background images based on the clock hand, if you have reasonably fast flash access and know where the picture data is (it does help if the data is stored continuously, so not having it scattered over the flash in different sectors; haven't studied the file system to see how the FS works).

How much time do you think is needed to read a byte from flash at a given position?
How much time to write a byte to LCD?
And of course this does require low level access to make it performant.

I'll see if I can come up with some pseudocode or C code to illustrate what I want, but it may be Friday or Saturday before I get to that.

I think you need to post up some code - I'm really not understanding what you're after.

drawImages can happily rotate the clock hands and overlay them on an unrotated clock background while updating only the area you specify, so I'm not entirely sure why you'd need 60 different background images.

Honestly, the answer to all those questions is 'it depends'. The best thing to do is to benchmark.

Flash memory is laid out intentionally such that everything is contiguous, so yes, you can just randomly access pixels if needed.

Let me try to clarify.
What I want to achieve is a 16 bit full-screen clockface.
My understanding is that if the hand moves I need restore (at minimum) the area that was covered by the hand at the old position that will not be overwritten by drawing the new hand.
So this is not about drawing the hand, it is about restoring the background.

Of course one can rewrite the old background in full: expensive.
Or you can rewrite only sections (as suggested by Abhigkar earlier in this thread) (bounding box based, but you would need images to draw)
Or you can store the background of every hand position an redraw that one (that is the 60 background images I was suggesting before, note that the background might be different when the hand is at a different position (I just want to have an image as watchface
Or you can restore the background based upon the "old hand": that is instead of rendering the hand, restore/re-render the background pixels that were covered when the hand was drawn at the previous position.

Or, rephrasing the problem:
Suppose as watchface I want to have a high-res image of my kid. When the minute hand moves from say 0 to 1 am looking for an efficient way (both CPU and RAM efficient) to restore the area that has been overwritten by the hand while at minute 0 after which I can write the hand for minute 1. To do this as efficient as possible, I would like to redraw only the pixels that are actually overwritten.

Did I now express my problem better?

What I want to achieve is a 16 bit full-screen clockface.

When the minute hand moves from say 0 to 1 am looking for an efficient way (both CPU and RAM efficient) to restore the area that has been overwritten

The code I'd posted a few posts back would do that, and the ability to restrict the bounds you draw to just the area including the old and new hands would get the redrawn area down to something sensible. Obviously it's not as efficient as something purpose built, but I feel it's 'good enough' and it's also really flexible.

But the best way to explain is with an example, so here's an analog clock with an image background, no flicker, and that's fast enough to include a second hand:

https://github.com/espruino/BangleApps/c­ommit/50a2df66d9835632bdddb0b5a44ba95ad9­f651be

If someone feels like a fun project it'd be nice to use the 'customiser' from the background image clock (https://github.com/espruino/BangleApps/t­ree/master/apps/imgclock) and add it here, so we could have a single clock with multiple different backgrounds.

I'm definitely up for ways to boost the performance of drawImage and drawImages (without increasing memory usage too much) though.