How long a redraw takes
Two bytes a pixel, eight bits a byte, at a clock you chose. On the 3.5 inch that is 61 ms of wire time for one full screen — four 60 Hz frames — and it is why clearing the screen every loop flickers on the big panels and not on the small ones.
The arithmetic is the whole article
A pixel on these panels is two bytes — five bits of red, six of green, five of blue. A full screen is every pixel. The wire carries eight bits per byte at whatever clock the panel is running.
That is all there is to it, and it produces a number you can feel.
Drag the clock down and up, and step through the panels. The 0.96 inch is around ten milliseconds and nothing you do to it will be visible. The 3.5 inch at its default 40 MHz is about sixty-one — roughly four 60 Hz frames — and that is visible as a wipe travelling down the glass.
It is a floor, not a measurement
The bar counts bytes and the clock and nothing else. On top of it sit the controller's own write time, the gaps between transfers, and whatever your code does to produce the pixels in the first place. Real redraws are slower than this.
Which makes the conclusion stronger rather than weaker: if the arithmetic alone says sixty-one milliseconds, no amount of tidying the sketch is going to make a full-screen redraw cheap on that panel.
What to do instead
Redraw the rectangle that changed.
A temperature reading that updates once a second does not need the screen cleared. Draw the old digits again in the background colour, or fill the small box they occupied, then draw the new ones. Two small rectangles instead of 153,600 pixels.
This is the habit worth forming on the small panels, where you cannot see the difference, because it is the one that makes the large panels usable.
When flicker is the problem rather than time
If the issue is that the screen visibly rebuilds itself — rather than that the sketch is slow — ask for a canvas:
display.begin(true); // true: please give me a framebuffer
// ... draw as much as you like ...
display.flush(); // one push to the glassYou draw into memory, and nothing reaches the glass until flush(). The eye
never sees a half-built frame.
It costs RAM: two bytes a pixel again, so 300 kB on the 3.5 inch, which realistically
means a board with PSRAM. begin(true) is safe to call anyway — if there is no
room it says so and draws directly instead, and hasCanvas() tells you which you
got.
When it does not work
You are clearing the whole screen and redrawing it. Instead, erase only the old value — draw it again in the background colour, or fill the small rectangle it occupied — then draw the new one. On a 3.5 inch that turns 61 ms of redraw into well under one.
A full-screen write blocks for as long as it takes, and on the largest panel that is most of a sixteenth of a second with nothing else happening. If the loop also has to read a sensor or service Wi-Fi, redraw less of the screen rather than trying to redraw it faster.
It fixes flicker, not time. begin(true) asks for a canvas in memory: you draw into RAM and push it once, so the screen never shows a half-drawn frame. The push still takes the same milliseconds on the wire, and the canvas needs the RAM — on the 3.5 inch that is 300 kB, which wants PSRAM.
Up to a point, and the ribbon decides where that point is. setSpiHz before begin takes a new figure; the failure mode when you go too far is a scrambled or half-drawn image rather than a crash, so it is safe to try. A shorter cable buys more than a bigger number does.
The lamp is a separate circuit, and on one panel in the kit it is wired upside down.
The backlight runs both ways →Edit this page — content/books/spi-tft-kit/how-long-a-redraw-takes.mdx
Questions about this product
See what other owners have asked, and read their solutions.
SPI TFT LCD Display Kit, 6-Pack from 0.96 to 3.5 inch
Loading discussions…
Discuss this article
Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.