ESP32 Forum

ILI9341 can work at 80Mhz SPI speeds.
I've made it using ESP8266 running @160Mhz and SPI @80Mhz. But you need to use short wires (10cm will work) or else high frequency signal requirements will come into play.
@80Mhz SPI you'll get around 60fps which is very fast

I've tried to replicate this on ESP32 but although I've managed to get SPI to run @80Mhz (or so I think...haven't checked on oscilloscope yet) the fillscreen rate will only go up to 45fps.
At gitter's EPS32 channel I was told that due to the dual core nature of the ESP32 some system tasks need to be done and that takes some of the performance away.
But I think that it pays off by having enough RAM to store an entire frame (or even 2) allowing to change the frame "offline" and then send it as a whole to the display.

Please find some rechearch I've done in video ... what you can be acheived ... real time of course ... step by step :

( Videos from my FB page with public share )

Step 1 : https://goo.gl/fwSoK6
Step 2 : https://goo.gl/XoEfs4
Step 3 : https://goo.gl/GThJvU
Step 4 : https://goo.gl/bPfpvN

Out of CPU performance the main bottleneck from my experience is the fast memory size available ... too limited

Been looking at the ESP8266 and "adjusted" the SPI library a bit and getting 40+ fps using SPI and a SSD1351 @16BPP.

As stated above, the real limiting factor is the real RAM available as the buffer for the screen itself is 32K!!!!

The other factor is unlike the Arduino Due or Teensy reading from flash must be 4 byte aligned or an exception is popped. Had to change my graphics library a bit to account for this... but without upsetting all the bitmap transfer code. Basically I handle the ESP8266 as if it was AVR and copy the entire bitmap or scanline into ram first then treat that line as "normal".

I altered the SPI library to include an ability to not wait after sending... and a function SPI.waitBusy(); that allows me to get rid of a lot of code overhead when writing dribs and drabs to SPI (like OLED commands). It allows the CPU to send the SPI bytes then allow me to do other stuff while it transfers.

As you can imagine, when updating 32K in 64 byte blocks (FIFO limit) getting rid of all the loop and function call overhead etc is a nice saving.

Getting a ESP32 this week and will "adjust" the SPI library there as well to allow for a no_wait option.

I got SSD1351 with full 25+ fps video on Arduino Due with 8 bit sound @6000Hz so the ESP32 should be able to do the same. The Due however had a lean and mean DMA SPI library I wrote from scratch and 96K of fast SRAM however runs at 84Mhz.

You may want to try the SPI driver that's native to ESP-IDF instead. It uses DMA and has the 'nowait' (queue and get the result later) option natively already.