SPI screens are notably slow. These screens are 240x240 pixels at 16 bit, so each frame is 115200 bytes of RAW data. If you clock the SPI at 40Mhz you can transfer a maximum of 4.8Mbps, that's 43 frames per second without taking in account the commands for the transfer (those are not much, but they count) and the delay between transfers. Then you need to add that while you are transferring data you are blocking the cores, so at the end you get those ~24fps with one single screen. To achieve maximum performance you can use DMA, the second core and a double buffer: in the first core you decode one frame, signal the second core to transfer that buffer, the second core prepares the DMA and triggers the transfer, meanwhile the first core starts decoding the next frame in the second buffer and so on, with this you remove any delay between transfers and maximize the time the first core can work in decoding frames. In fact the first core will end decoding a lot faster than the DMA transfer to the screen so you will need to synchronize the cores and ensure that the DMA transfer has finished before signaling the start of a new transfer.

Would be great to see how to use lvgl or similar to create a fluid ui with for example smooth scroll and page transition animations.

GIFs have always been an extremely compute intensive format. Those sites where back in the day you could download animated emojis from would have your desktop CPU running at 100%. The smoothest animations I've seen so far on the ESP32 are from 'Lottie'. No idea how easy or hard it is to get running though.

Awesome Experiment. Thank you . Please more of that!

The ESP has 2 x SPI: HSPI and VSPI. You can use the first SPI with the first core and the second SPI with the second core. This should cut down on latency. You can also try other animated-GIF-like formats, such as APNG, WebP, AVIF, MNG and FLIF, to see if they lower your processing overhead.

thanks man, very inspiring

The power consumption part not correct. You just checked the absolute max io current of the ESP chip itself. 1: you should never reach absolute max. There is a recommended max value in the datasheet. 2: IO pin and power pin is not the same. You are not powering the screen from an IO pin but from the 3.3V regulator on the board. So you should check the datasheet of the LDO not the ESP32. 3: the current draw that you measured is on the 5V USB rail, but your screen is powered from 3.3V. If there is a linear regulator then the current is roughly the same. But if you have a switching mode PSU then the 3.3V current is like 5/3.3 = 1.5 times more then the measured on 5V.

very nice!!

I’ve been doing a few screen based projects lately involving esp32’s and screens, and memory management has been a real struggle. But Incase it matters, on top of confirming what others have said, (I’ve yet to have any problems with spi at 40mhz, and atleast on the S3 chip 80mhz has been pretty happy too), if this still turns out to be insufficient remember that on top of having two cores and command queue capabilities, you also have 2 hardware spi buses, HSPI and VSPI, so you could split the screens 3+3 and cut the bandwidth toll in half.

interesting thing about GIF decoding is that decoding speed tightly depends on content you have in your GIF, so it means that if your GIF frame has lots of different pixels, wide palette (but it will still be limited to 256 color palette i think) - decoding rate will be slow because decompressor output might redraw large portion of screen, but if your GIF frame has, say, text characters appearing on black background (like that console animation) - frame rate will be high because decompressor will only give you "parts that have changed since last frame", if i understand the process correctly. there is also separate song and dance around transparency handling, to do proper which you need a large framebuffer, but you should be good if your gif does not use transparency pixels

Looks nice.

Decompress once and store the decompressed data. Then just send data[frame++]. No more bottle neck in esp32.

Je vais t'checker tes vidéos de proche! Je suis en train de (re)faire mes fichiers 3D pour imprimer un blaster DL-21 (Star Wars) et je voulais lui rentrer un écran rond dans le scope un 2e carré dans le body! En plus des piou-piou et d'une DEL qui pourrait flasher fort dans le canon. Aaaaanyway... Lâche pas la patate!

I'm not sure what the default is for TFT_eSPI, but you may be able to bump up the communication speed as well. 40MHz is usually pretty stable with an esp32, and I've had some luck with 80MHz as well, although it won't help much if the bottleneck is in managing the gifs themselves, and not the transfer rate

It would be great to see the sequence of the plans that Leia gives to R2 on how to destroy the Death Star

Gives us an insight into the graphical capability of the ESP32.

SPI communication has no defined speeds the way I2C does and can easily handle 10mbps. So, it's definitely the EPS32's limitations causing the framerates.

Thats awesome this is exactly what i need but only with 5 screen 👏

nice

I think it would be great if you could make a digital version of the nixie clock on these displays or a simple digital clock using images

Honestly I think that the mirroring is caused by all the displays reading the same data.. since they are in parallel and you wanted only to play the gif on the first display anyway, i think there was a error in the code that pulled all CS pins active, therefore every display read the data.. imho the real limit is the spi bus, because with every display you need to send more data through the same bus.. maybe try just blinking the LCD from black to white and see the limit.. you will bypass delay with reading the gif and measure the real bandwith to the display. btw i'm also working on a project with esp32, i'm making a led bus panel (using P10 monochrome displays) to show the line number etc. and i was blown away by the performance of the esp32

Hi, thanks for the video! Just one queation, is it possible to use bigger screens, such as a 3" circular display?

Waiting part2...!! Get help from all smart programmers in order to let second core participating in the decoding process and use all available hardware to its limit to transfer data.

Can you try splitting it across two SPI buses? I’m not super knowledgeable about this, but you are sending all the data down a single serial bus rather than paralleling the data transmission. I’m assuming there’s a time cost involved in the whole chip selection function.

You are my hero - I managed to get two displays to work, thank you so much! I have a question please: Can you tell me how to make the GIF animation slower? If I put in more frames, the gif gets too big... But I need it to be slower - can you tell me which parameter in the code to change? Thank you so much!

I have a question for you! I run the 6 screens and everything runs good! I want to use a tft display gc9107 T-0.85 from lilygo, the first screen runs goog but to fast on 100 fps, when I add the second display the code upload good but the screen blocks and the serial monitor shows error! Do I need to modify the code for this displays?

Isn't the last example just broadcasting the same image to all screens, therefore only using 1/6 of the bandwidth?

Could the program itself be doing suboptimal processing for such a task? (Sorry, im a software guy 😂)

Hello, I am your fan. I used your code using esp32 dev module on 30pin. But why does the gif change very quickly on one LCD and the other LCD does not respond? What is the reason??

can you please explain how to assign CS pins through the code?

with 6 screens, you can build an electronic dice

I have modified it by reading the gif on a micro SD and using 2 tft displays, it has succeeded but I have a problem with the fps dropping

Try this on a Teensy 4.1 - 600mhz speed, ability to increase ram to 8 and even 16mb using PSRAM chips and 3 SPI bus lines!

4mb Ram? it does have 512kb ram i think? and 4mb flash ....

how do i get my 240x320 tft display esp32 to display gifs? im a complete novice

your english is cookie.

Can you make the eye size? ukposts.info/have/v-deo/g5Vih4BvZGyrq6s.html Because you have a video tutorial about the eye but it is not as big as above thank you

But these are just reading the bitmaps from memory and don't have to do any decoding, right?

Esp32-s3 should perform better