I have 1.8 TFT display for Arduino Nano and it changes color very slow. When I try to change the color of the whole screen I see how it changes color line by line. I use "Adafruit GFX graphics core" and "Adafruit ST7735" libraries to change colors.
Question: Slow refresh rate of 1.8 TFT display is due to limited computation capability of Arduino or 1.8 TFT display itself or library used?
The ST7735 TFT uses SPI to communicate. That can never be particularly fast.
At 160x128 pixels with 16-bit colour depth that gives you 327680 bits that you need to transfer just for the colour data. On top of that you have 88 bits to set up a drawing window (11 bytes of "set X coordinate and width" [5 bytes], "set Y coordinate and height" [5 bytes] and "start drawing" [1 byte]).
That's a total of 327768 bits that you need to transfer.
Now the transferring of that data is at the mercy of the SPI clock speed. How fast that can go depends on what the ST7735 can work at and the quality of your wiring (if it's a shield you can almost discount the wiring). Assuming you can operate at the maximum 8MHz that the Arduino can run SPI at (which is probable) then you get:
8,000,000
--------- = 24.4 frames per second
327768
That is the absolute maximum theoretical speed, and doesn't take into account any work done by the Arduino to actually send the data. The SPI library is completely blocking in its operation and each pixel has to be sent separately as one blocking transaction. So you can expect about half that rate in reality, if not less, while it loops around and sends each pixel, then blocks waiting for the pixel to be sent.
And of course that's assuming running at the maximum speed. In reality that probably isn't happening. Libraries that use SPI often choose the "lowest common denominator" for their SPI speed (if they actively choose a speed at all) so that the library "just works" in the majority of cases. So the speed the library is running at will most likely be considerably lower than the actual maximum speed you could run at.
For example, if it runs at 1MHz instead of 8MHz then you will get about 3 frames per second (which is more like what you are describing).
So examine your chosen library and see what it does in the way of configuring the SPI speed. If it doesn't do anything then consider adding code to increase the speed. If it does then consider increasing the speed it operates at (see the SPI library reference for more details).
TBH, though, a small Arduino is seldom a good choice to control a TFT screen. At the bare minimum you really need a chip with far more memory so you can draw graphics "off-screen" in a framebuffer, and then use DMA to transfer that off-screen buffer to the TFT screen over a 16-bit parallel connection at high speed while leaving the CPU free to do other jobs. Or even better a microcontroller with a built-in TFT controller to directly generate the correct drive signals for a TFT panel and store the whole screen image in internal RAM.
Given you use the last library versions and have the cables right - it is hard to guess without your code.
So to check if it your code load one or two of the library examles and see if it works there.
Another option is to set SPI speed the set with begin(freq) is not working, because its wrong see more in this issue.
If the problem still exists come back with wiring and code used. The nano is not the best choice with TFTs but runs decently.
