TouchGFX screen transition graphics corruption

[Holo]

I have just created a fresh test project based on TouchGFX 4.8.1 but I am seeing graphics corruption during screen transitions. The graphics are otherwise perfect and normally look correct, it's just the 'old' screen becomes corrupt when the 'cover' screen transition is in progress.

Also have a video showing the issue here: https://youtu.be/R9Jg1pv2DIw

I am using a custom board based on an STM32F411 and a SPI LCD (320x240 with integrated ILI9341 driver). It uses the partial framebuffer strategy (3 blocks x 9600 bytes) due to the processor not having enough RAM for a full frame buffer.

I'm pretty sure I can rule out my LCD driver as looking at the pixel data that gets passed into touchgfxDisplayDriverTransmitBlock() it appears the data is already corrupt, possibly an issue with TouchGFX itself?

I did see another post where they had what appeared to be the same screen corruption issue but they fixed it using a full framebuffer, which I cannot do unfortunately.

Does anyone have an ideas what's going wrong or how I can fix this?

[VKost.3]

Hi!  

In the HAL.hpp file, in the uint16_t* getClientFrameBuffer() function, change frameBuffer1 to frameBuffer0! helped me.

uint16_t* getClientFrameBuffer()

  {

    if (USE_DOUBLE_BUFFERING && getTFTFrameBuffer() == frameBuffer0)

    {

      return frameBuffer0;

    }

    return frameBuffer0;

  }

[Holo]

Thanks for the suggestion, however unfortunately this does not work.

In fact getClientFrameBuffer() never gets called, presumably because this is a partial framebuffer strategy project (also worth noting USE_DOUBLE_BUFFERING is set to false).

[N. SANTINI]

Hi,

Be aware that in partial frame buffer strategy you cannot use any type of screen transition.

From what I see you are using the "cover" transition that involves a intensive refresh of the display as the transition progresses, in the last steps of the transition you update almost the entire screen, partial frame buffer is not meant for that.

I suggest you change the transition to "wipe" (similar to "cover" but only a few lines updated at each step) of "block" transition.

Best regards,

Nicolas

[Holo]

Hi Nicolas,

Please can you point me to where that slide came from? I can find very little information about the transitions within the touchgfx documentation.

It's disappointing to hear that the partial framebuffer strategy cannot deal with the cover transition. I knew it would have slight performance limitations as it's progressively redrawing more and more of the screen on each tick but I don't see ~15-20fps as an issue for my application.

Forgive me but I don't understand why the "cover" transition is not technically possible with the partial framebuffer strategy. It only ever needs to draw the new screen which becomes progressively more visible - the remainder of the previous screen will always remain in the LCD's own frame buffer. It appears touchgfx is currently redrawing the entire screen during the transition even though only a small part of it has changed - this doesn't seem correct to me, at least not for the LCD and framebuffer strategy I'm using.

Thanks.

[N. SANTINI]

Hi,

Sorry for the late answer...

I created this slide on my own for a training.

Regarding the cover transition the problem is the amount of data that needs to be sent to the display.

At the beginning of the transition it is just one vertical line, then 2, then 3, etc and getting close to the end of the transition it is the full screen that must be sent.

But in partial frame buffer strategy sending a full screen refresh means a large amount of SPI transfers and rendering processes since you do not have a full frame buffer in RAM.

This results in flickering of the display since the larger area of the display needs to be refreshed, the longer the process.

You are right, the display has its own frame buffer, it reads it 60 times per second, to avoid getting tearing you must update this memory during the blanking period, the time slot between the last line read and the next frame first line read. If the update of the memory takes too long then the display controller starts reading, in its own frame buffer, the lines from frame n and ends reading frame n+1 or even n+2, thus the tearing effect.

see : https://support.touchgfx.com/4.18/docs/development/scenarios/lowering-memory-usage-with-partial-framebuffer#display-tearing

Best regards,

Nicolas