Text Glitching When in Portrait Mode

[montea]

Hello,

TouchGFX seems to have some sort of a “bug”, where in PORTRAIT orientation the text will glitch with some weird white lines, unless there is an image in the item-tree situated ABOVE text items. It doesn’t have to be any image in particular, but MUST be an image.

If there isn't any image added, then every text element is glitched the moment I rotate to PORTRAIT:

touchgfx::HAL::getInstance()->setDisplayOrientation(isPortrait ? touchgfx::ORIENTATION_PORTRAIT : touchgfx::ORIENTATION_LANDSCAPE);

The glitched text looks as such (see the white weird lines corrupting the text):

This is my item tree in TouchGFX Designer (I also tried removing the background but the white lines remained):

Then, if I add any kind of image, any text area under that image in the designer stack-up, it will be displayed without glitches and any text area placed above will glitch as such (Note, the XY location in the screen does not affect this, only the stack-up arrangement!):

This is the stack-up to produce such result.

Note that the text 'Before' can be moved anywhere on the XY location on the screen and it will still glitch, whereas the text 'After' will not glitch. If I move both 'Before' and 'After' to be under the image1 in the stack-up, both text items will be glitch free :) 

Is there a known cause for this bug, can anyone else reproduce this? I am ok to have a workaround I posted here, however it feels more like a workaround rather than a solution.

[Osman SOYKURT]

Hello @montea,

I was unable to reproduce the issue on my side. Could you give more info about your project? Which STM32 MCU do you use? Which version of TouchGFX designer do you use? Have you switched orientation of the text as well as the display orientation?

[montea]

Hi @Osman SOYKURT,

We are using an SOM from Emcraft based on  STM32H7. I was getting this issue with both an older (4.24.0) and also the latest versions of TouchGFX designer 4.25.0. I do not believe this to be an issue of the designer itself but rather some memory loading issue. 

You said you couldn't reproduce this, would you be able to share a screenshot of the component tree in the designer and also pictures of the screen in portrait and rotated? Also, are you re-rendering the screen on every frame or only on data change? I noticed that I can "fix" this by re-rendering (calling invalidate()) the screen on every frame (so 60 times per second), however that puts a bit burden on the MCU...

Monty

[evervoid]

Hello @montea ,

I have similar issue on stm32h747. The glitch pattern on the text area is exactly the same as yours.

I'm using a 480(H)*1920(V) screen, in landscape mode. The elements on the screen are a box in the background, some text areas and dynamic graphs. The text area and dynamic graph are in a container.

When I update the text, it has a very high chance to show the glitch. To make the glitch disappear, instead of calling textArea.invalidate(), I have to invalidate the container whenever the text is updated.

Have you found the cause of this issue?

[mathiasmarkussen]

Hello,

Setting display orientation in TouchGFX at runtime is not supported, it relies on assets to be generated "rotated" at compile time. If you need your UI rotated at all times, you should set the option in Designer under Config -> display.

If you need rotation at runtime, you can either duplicate each screen with a rotated version and work around it that way, or you can rotate the framebuffer contents. This thread has an example that shows how to accelerate a rotation of 180 degrees using the GPU, you might be able to get some inspiration from that.

On another note, I can see that your white background is a circle. Using a box and letting the display mask take care of the corners will be a lot faster.

[mathiasmarkussen]

As stated above, runtime changes of display orientation is not supported, are you doing that as well?

Based on your description of the issue (invalidating the text area not working), the text has moved, but the actual text area has not.

You can try to call something like 

textArea1.setTypedText(textArea1.getTypedText());

 to re-initialize the text area. I'm not certain if this will invalidate the area, otherwise it may make it possible for you to invalidate it. afterwards.