Unfortunately the SPI interface and the 'high' resolution (320 * 480) and the SPI interface working in 24 bit mode (only) means that there is a lot of data to transfer. (Using the HSPI bus at 80MHz is obviously a good idea here)
I hit on a snag using the component - I got no clock signal on the SPI bus (on A23) looking at the data on a logic analyser - the SCLK pin did nothing (I've maybe damaged my esp32 board?)
After a fair bit of fiddling (!) starting with the component - I finally got the display to work by changing the clock pin - now I'm using A18 this is on the other side of the board so messes with my neat wiring

By then - I'd rewritten some of the component to use a display buffer and transactions instead of individual bytes for the SPI. The display would use 153000 bytes for 256 colour - so I went for a 16 colour (4 bit) compromise. This limits me to an esp32 or other MCU with a decent chunk of RAM.
I rewrote Initialise (see above) and Plot (here called plot_copy) I added a Display macro - to output the data - and also a Display_Copy - this only outputs data if the line has been modified (so for displays with few changes is a lot quicker...)
I also added a SetColour - and a lookup table for the 16 colours.
After all the work - is it quicker? I did a couple of demos (here printing Hello World and drawing 10 random circles) and yes it is. The speed improvements depend on how much is displayed and how much is drawn before Display_copy is called. It is noticeably faster than the component (using the esp32 'fast' mode) It's never going to allow animation though

It still needs a bit of work - Plot_copy (needs changing to plot) maybe could take a colour index (0..15) rather than setting FG and BG colours. I use colour[0] as BG and 1 as FG here. Plot can also handle display rotations.
If anyone would like to play -