How to handle correctly "buffers" and "sprites" to completely remove flickering ?

[mistertai]

Hello Bodmer,

I am learning programming esp32 (plugged to a classic TFT 320x240 screen + differents sensors), and of course I discovered your fantastic library. Congratulations for this amazing work !
I had to recognize that my curiosity pushed me to explore the graphic capabilities of your library really FAR beyond my initial needs... and now probably TOO FAR beyond my real programer skills... :)
So please let me expose where I lost myself in the deep space...

I'am trying to create a gauge with a jpeg background and a moving needle.
In the example you published (which was the source of my inspiration), the principle is to backup a zone image in a buffer, then to create a rotating needle in a sprite, and then to push the sprite to the TFT. At the next loop, the buffer is patched back to the TFT, and it loop forever this way....
Great, and working perfect !

At some point, I decided to find a way to totally remove the residual flickering of the needle (generated by the alternance of patching back the buffer to the TFT and writing over the needle with the sprite).
To do so, I tried to use a kind of "double buffer" principle but so far I completely failed...

Is there a way to achieve it in an academic manner ?
I tried to used in my code some "transfers" between multiples "buffers" and "sprites" but it seems it is not possible to use functions like sprite.readRect(x,y,X,Y,buffer) or sprite.pushRect(x,y,X,Y,buffer)....
So, my questions are:

• How to grab a copy of a jpeg area from the TFT to a sprite ? (is it only possible from TFT to a buffer?)
• How to grab a copy of a jpeg area from a sprite to a buffer ?
• How to push image from a buffer to a sprite ?
• In general what are the rules and principles governing this types of functions ?

Many thanks for your help,
Kind regards

[Bodmer]

This is one of the more difficult tasks to achieve unless the images are small due to the limited RAM available on most low cost processors.

To answer you questions:

1. A sprite is really just a reserved area of memory. The createSprite function returns a pointer to the memory area reserved. You have to cast this to either a 16bit pointer for 16bpp, or an 8 bit pointer for other N bpp sprites. Be aware that for 16bpp sprites the colours are stored byte swapped, so DMA can be used directly to send them to a SPI port.
2. The simplest method is to render the jpeg directly into the sprite. However it is possible to use the pointer above as the destination memory area.
3. You can use sprite.pushImage providing the buffer has the correct endianess format.
4. Some rules are as noted above. The library will crop images pushed to sprites. If you copy memory buffers to the sprites with memcpy for example be careful not to overrun the end of the sprite buffer.

Other approaches are to store the decoded image in SPIFFS/LittleFS and pull it out when needed.

Ideally two large memory buffers are needed, one could be in FLASH (SPIFFS or LittleFS) or in a PROGMEM array. Buffer 1 to contain a clean image, which is copied into Buffer 2 then the needle added and then the whole of Buffer 2 copied to the screen. Clearly the buffers only need to cover the part of the screen where the needle sweeps. In the next loop Buffer 1 is copied to Buffer 2 and the needle drawn in the new position.

A more memory efficient approach is to make buffer 2 just large enough to refresh the area where the needle was last drawn and the new needle area. Clearly this needs coordinate calculations. to get the buffer rendered in exactly the right place, so large beffers are the simplest.

If your ESP32 has PSRAM then full screen buffers can be allocated, but the larger the buffer the longer it takes to copy to the screen.

The main probelm with large buffers is that the needle update time is large so the movement in not fluid. The "Animated dial" example was mainly intended for things that change slowly like temperature or humidity, then the needle flickers only ocassionally when it moves. Clearly you want to avoid a noisy signal in this situation by averaging or setting bound for the delta change before a redraw.

[hairybaboon]

I have a two part issue related to this. 1. I threw in some millis() calls to track timing and the big part of the timing cost is the tft.readrect call, the actual writing of the old buffer and the writing of the sprite are quite fast. So when you first write the old buffer, then read the new area, then write the new sprite, you have a long pause for reading, not for rotating / pushing. I tried to look for a way to read the image of another sprite, rather than the screen itself, but don't think that exists in your library. If I'm using one sprite for my background, then being able to pull the background values from that sprite, then hold in buffer and push should be much faster, as that's all chip internal rather than communicating with the board (as I believe tft.readrect does).

2. I'm running the buffer in the Animated_dial.ino but it doesn't seem to properly replace the data that was behind it (needle sweep is like an eraser of the major tic numbers of the dial). Is that a fault of my wiring (i.e. not connected up properly to the screen's read pins)? For reference, running an ESP32 feather v2 (adafruit: https://learn.adafruit.com/adafruit-esp32-feather-v2/pinouts) and a 240x240 TFT (adafruit: https://learn.adafruit.com/adafruit-1-3-and-1-54-240-x-240-wide-angle-tft-lcd-displays/pinouts)
   -->EDIT: I did some more googling and know why the buffer isn't working - the screen is write only "SO - this is the SPI MISO (Microcontroller In Serial Out) pin, it's used for the SD card. It isn't used for the TFT display which is write-only. It is 3.3V logic out (but can be read by 5V logic)".
   So for a write only screen, is there a way to read an area out of another sprite in order to replace with that info instead?

[Bodmer]

You may get some ideas from the zipped example posted here:
#860 (comment)

[hairybaboon]

That helps greatly. Basically you create a background master copy and then push from one sprite to the other, then apply the needle on top, then plot.

The viewport basically narrows the actual area of a sprite that is plotted when pushSprite is called, and also changes the upper left corner's location (i.e. you are setting where on the main screen the upper left corner of the viewport is positioned). That way, while you are still holding the full needle sweep area twice in memory (plus needle itself), you only have to refresh a narrow screen area each time.

I believe this means that the two spr[*] could actually be of different size, spr[0] just needs to be big enough to hold any plausible needle angle, while spr[1] needs to hold the full editable range (I assume that's way faster than repeatedly loading from bitmap to a sprite). The benefits there I guess depend heavily on write speed / total memory available.

[hairybaboon]

I think i'm missing one piece of this. What's the point of calling viewport to the smaller area when the following command is the pushSprite call that only does a subset of the overall sprite?

// Push a windowed area of the sprite to the TFT at tx, ty
bool     pushSprite(int32_t tx, int32_t ty, int32_t sx, int32_t sy, int32_t sw, int32_t sh);

[Bodmer]

It speeds up this operation:
spr[1].pushToSprite(&spr[0], 0, 0);

Because a smaller area is selected to overwrite in the destination sprite.