How to implement (algorithm) rendering of graphics "by layers" on MK?

Question

Do it yourself

Good day to all.
The question is this. There is an MK (avr arm) and a graphic display for it (TFT 320x480). Specifically, in this case, it is necessary to implement the output of readings in the form of an analog indicator (+ in the free space of the screen - a graph, but this has nothing to do with the voros). The indicator is displayed by the substrate in the form of an ordinary picture, its arrow is also a picture. Resp. how to most competently implement the output of this information on the LCD screen?
The solution is straight forward - turn the arrow to the desired degree, redraw the background, draw the arrow on top of it. This is the simplest solution, but not the most elegant in my opinion. The fact is that if the LCD is, say, 640x800 pixels, redrawing will take a very long time and will be noticeable to the eye. I would like feng shui and beauty.
The second solution that comes to mind is to read the area with the arrow already drawn from the display, calculate the area with its new location and replace the first with the second, thereby minimizing the redrawing area, since the dynamic area of ​​the "analogue indicator" God forbid 35-40 percent.
Maybe someone else will throw some ideas, share personal experience so to speak. I didn’t find something ready-made, even if ported from arduino to a regular AVR C.

Answer 1

Without a double buffer, it's easiest to remember the "old value" where the arrow was, and the new value where it needs to be redrawn. It is also not the most convenient option, but it can be implemented like this:
- Erase the arrow according to the old coordinates. (Restoration of part of the background)
- Drawing an arrow at the new coordinates.
Pros - Doesn't need a lot of memory. In fact, only data about the arrow, coordinates and the like.
Cons - At least two frames of rendering.
Another option is to create a temporary memory buffer in which the modified picture will be drawn, and then display it on the screen (replace the rectangle).
Cons - Requires memory. Lot. You can try to grab more memory than is in the chip.
Pros - Done in one frame.
Why not use something else? Sliders/bar/numbers, eg. They are easier to draw quickly.
Although, if you so want - then ... as they say.
But personally, I missed these arrows for myself.

Answer 2

If it is a pity for double buffering of memory, then it remains only to fence a non-trivial redrawing algorithm. For example:

1. Create a mask for the arrow: from the transparency channel (1 bit) of the arrow at the end position, subtract the transparency channel of the arrow at the start position.
   
2. Fill the area with the mask with the image of the arrow in the final position.
   
3. Create a fill mask: from the transparency channel of the arrow at the start position, subtract the transparency channel of the arrow at the end position.
   
4. Fill the area with the mask with the image of the background.