Only you know what your data is like. There is always a balance between individual pixel addressing versus re-drawing a full rectangle.
For example. Drawing a letter in a "thin" font uses less SPI bytes with individual pixels than painting the full rectangle.
Hey-ho. You can calculate the minimum time very easily. e.g. 240x240 16-bit pixels = 38.4ms @ 24MHz. (26 fps)
In practice this gives you the performance limits. You can do all of the calculations for the "next" frame while DMA is blitting the current frame.
This uses tremendous resources. e.g. two full screen buffers. Or perhaps two half-screen buffers. Look at Bodmer's recent example video in the Displays Forum. https://forum.arduino.cc/t/tft_espi-support-for-raspberry-pi-pico-added/702551/2?u=david_prentice
No, I have never used SAME51 or GC9A01. I would need to check the datasheets. And test the actual GCA01 throughput. (the ILI9341 accepts much faster SPI than the datasheet says)
I have only used SAMD21 (which is a bit crap)
The 256x32 SSD1326 is a totally different controller designed for grayscale OLEDs.
TFT controllers tend to be much bigger and faster. After all they have more pixels and 262k colours versus 16 grayscales.
Oh, it seems a mystery why anyone would buy a grayscale display and then use in monochrome !
David.