Question: Screen refresh flicker even with no change

[klaasdc]

Hi,

I'm using this library on a Teensy 4.1, using the framebuffer. Generally, I draw my graphics to a canvas (Adafruit GFXcanvas16), and then push it to the display using:

tft.writeRect(0, 0, DISP_WIDTH, DISP_HEIGHT, canvas1->getBuffer());
tft.updateScreenAsync(false);

I notice that even when the written canvas is always completely black, there is a flicker in the display corresponding to the screen update frequency. In fact, doing any display update generates this flicker. Is this normal?
Can it be avoided somehow?

[klaasdc]

I experimented a bit more and noticed that if the calls to update the screen are faster (e.g. 15 p/s instead of around 6 p/s, the flicker disappears. But I still don't understand the source of it. Leaving the screen black, but calling updateScreen at 6 per s makes it flicker, despite the content of the screen is untouched.

[KurtE]

Sorry, been busy playing with a different board.

Flicker and the like may depend on how it is used.

For example with the updateScreenAsync, did you wait until the screen update completed before changing the contents of the frame buffer and likewise before you issue a new updateScreen.

Also what type of memory you are using for the frame buffers. If you are using PSRAM, it is slower and maybe slows things down.

One current advantage of not using the Async version, is I have code in place that computes what area of the screen that has been updated and only update that bounding rectangle... I have played with adding that to the DMA version, but not the continuous update version.

Not sure if you are seeing flicker or tearing. There is another ILI9341 library (ILI9341_t4), that more or less does not have any graphics, it is setup to be able to use something like VGL, and it does some more extensive comparing of buffers, and only update those regions that changed... Also has some synchronization code, to time output to hopefully avoid tears.
Not sure if that would be a better match for what you are trying to do.

[klaasdc]

Hi Kurt,

Thanks for the reply! In my code I always write to a canvas object, and at the last moment I write that to the screen. Basically the following code in a loop, but limited to a fixed update speed (e.g. 6 or 15fps).

<Drawing to canvas1>
tft.waitUpdateAsyncComplete();
tft.writeRect(0, 0, DISP_WIDTH, DISP_HEIGHT, canvas1->getBuffer());
tft.updateScreenAsync(false);

The complete code is quite extensive so I will doublecheck if I don't have some leftover updateScreen() hiding somewhere, but I found it odd that the flicker is only appearing at (very) low update speeds. The flicker happens independent of the changes to the screen content, it seems.
How can I check whether the buffers are in PSRAM?

[KurtE]

Sorry, I noticed that this issue was not resolved.

Flicker is always an interesting problem, that I don't have any complete answer for.

The writeRect code is pretty simple, especially when using a frame buffer. It simply copies in your data into the displays frame buffer. And the updateScreenAsync will redraw the entire screen. That is it sends commands to the screen to set the update region and then sets up DMA operation to write out the entire bytes for the whole screen.

As I mentioned in the first reply the ILI9341_t4 library has support in it, where it will compare two buffers and only output the differences, which can be a plus. If I remember correctly they also try to setup when is the best time to update the screen in order to avoid a tear operation. By looking at what scan line you are on... There is a command that can work if your display has MISO line
uint16_t ILI9341_t3n::readScanLine() {
It has been awhile, so not sure what the best values are for this. I think some try to time it such that they fill in the data such that you maybe always fill in just behind where the display is looking...

PSRAM - you only use this IF you are a Teensy 4.1 with PSRAM installed and ask for it, either using EXTMEM define or using the extmem_malloc requests.

You can detect it codewise by looking at the address. It will start at:
ERAM (rwx): ORIGIN = 0x70000000, LENGTH = 16384K

[klaasdc]

I recently tried the ILI9341_t4 library, and that solved the flicker. So I eventually moved the application over. The memory requirements are much higher though.
My display does not have the MISO line, so I suppose it does not do any vsync. Under a few circumstances I can still notice flicker (e.g. when drawing text on top of an image).
Additionally, increasing the SPI speed also reduced the flicker. Due to my board layout the SPI wiring is quite long and I cannot exceed 15Mhz.

[doctea]

Perhaps not the same issue, but I was also struggling with a subtle flicker (not tearing) that became worse if my processing loop wasn't drawing fast enough.

This was using updateScreenAsync(false), from framebuffer in PSRAM although it was the same also from main memory, and also making sure that asyncUpdateActive() returned false before changing the framebuffer.

Previously my project used an ST7789 with the ST7789_t3n library, and would flawlessly with a rock solid image with no flicker, and as nothing I did with my project improved the flicker but I had already made PCBs to use the common ili9341 board layout, I just stayed with it.

I recently found some displays on aliexpress that claimed to be ST7789s and had the exact same layout and dimensions as the ili9341 board, so I ordered some of those. They are similar but different -- these boards say 'v1.0' on them while the old board says 'v2.0'. But I rapidly discovered that they were not in fact ST7789s but ILI9341 again, despite what it said on the label...

HOWEVER! The image on these 'new' ('v1.0') boards seems much better than previously. It seems brighter, and even with no code changes, it is flicker-free. But it also requires a different rotation setting (1 instead of 2, which breaks the rotation logic in setRotation()), and a different RGB order (MADCTL_RGB instead of MADCTL_BGR), so I have had to modify the library a little to account for this.

(Also oddly, when I first tried this board I was getting a lot of tearing, so I tried to implement double-buffering, which I could not seem to get working quite right, and ended up with very slow framerate and flickering again. But after reverting my attempts at double-buffering from my code, the tearing is gone, which is a bit of a mystery for me -- perhaps there was a change I had not known I made. Even stranger -- when I swap back to using the previous board, I now get tearing?!)

So - it seems there is a possibility that the hardware itself can contribute to these problems somehow!