TouchGFX widget visible on empty screen

Question

I'm evaluating the TouchGFX tool additional to the STM32-Platform. Everything works "fine", like the interaction with some hardware resources of the STM32F746G-Discovery board, but there is another issue.

I created a custom keyboard (as seen as in the TouchGFX examples), but even before I enter the last Screen, where it should be visible, it appears on the screen before. I checked the View.hpp/.cpp and ViewBase.hpp/.cpp of both screens and I don't know why it is as it is.

Screen3View.hpp (Where the keyboard should be visible)

#ifndef SCREEN3VIEW_HPP
#define SCREEN3VIEW_HPP

#include <gui_generated/screen3_screen/Screen3ViewBase.hpp>
#include <gui/screen3_screen/Screen3Presenter.hpp>
#include <gui_generated/screen3_screen/Screen3ViewBase.hpp>
#include <gui/screen3_screen/Screen3Presenter.hpp>
#include <gui/common/CustomKeyboard.hpp>
#include <touchgfx/widgets/ButtonWithLabel.hpp>

class Screen3View : public Screen3ViewBase
{
public:
    Screen3View();
    virtual ~Screen3View() {}
    virtual void setupScreen();
    virtual void tearDownScreen();
protected:

    CustomKeyboard keyboard;

};

#endif // SCREEN3VIEW_HPP

Screen3View.cpp

Screen3View::Screen3View()
{
    keyboard.setPosition(16, 16, 400, 240);
    add(keyboard);
}

Screen4View.hpp (where the keyboard should not be visible)

#ifndef SCREEN4VIEW_HPP
#define SCREEN4VIEW_HPP

#include <gui_generated/screen4_screen/Screen4ViewBase.hpp>
#include <gui/screen4_screen/Screen4Presenter.hpp>

class Screen4View : public Screen4ViewBase
{
public:
    Screen4View();
    virtual ~Screen4View() {}
    virtual void setupScreen();
    virtual void tearDownScreen();
protected:
};

#endif // SCREEN4VIEW_HPP

Screen4View.cpp

Screen4View::Screen4View()
{

}

all other.cpp of the TouchGFX files "say" the exact same thing. Just Screen 3 should have this keyboard, and not Screen 4 too.

So if anybody has an idea why it is like that please answer. :)

Thank you very much.

zrrbite · Accepted Answer · 2019-11-16T08:32:46.230

3

When you "switch screens" in a TouchGFX application this new frame will be rendered to some framebuffer memory (the complexity of running a simulator vs target hardware with multiple framebuffers is irrelevant when it comes to explaining what you're seeing).

When you activate a screen that renders nothing (like Screen4 since it has no widgets) you're basically staring at the state of the framebuffer left by the previous frame (which was Screen3 with the Keyboard). Imagine if Screen4 was the first thing you were trying to render - Then you would just see garbage/uninitialized memory.

This is why you're seeing a Keyboard, even if it is not even a part of Screen4. Add a box to Screen4 covering the full dimensions of the canvas and you won't see the previous framebuffer state anymore. This would be the same for any widget.

If you compare the glass of the LCD to a window in your house, by adding a box you're basically closing the blinds to that window, now unable to see the "Keyboard" just on the other side.

edited Nov 16 '19 at 08:32

answered Nov 14 '19 at 13:01

zrrbite

1,180
10
22

Thanks for your answer. I've created the canvas with the TouchGFX designer and added buttons, a box,.... and it did the said problem (the ScreenviewBase.cpp looks right) . Do I need to add a box manually in the Screen4View.cpp/.hpp? – Melissa123 Nov 15 '19 at 07:40
1

Exactly right. In order to not see the state of the framebuffer from a previous frame you must cover the entire canvas in all your screen definitions, either by box (single color) or image. – zrrbite Nov 15 '19 at 08:58
You're welcome! Ping me if you post more TouchGFX related questions. – zrrbite Nov 15 '19 at 09:25
That's very nice of you. – Melissa123 Nov 15 '19 at 09:45
I've got antother question. If you could help me... :) https://stackoverflow.com/q/58874343/11662983 – Melissa123 Nov 15 '19 at 12:26

Adwait Patil · Answer 2 · 2020-04-12T11:39:17.737

zrrbyte's answer gives a nice explanation of why one would face the problem that the OP is facing. The solution given (forcing a background image on the screen) works, but an alternate solution is to fill the frame-buffer with some color. For STM32F746G-DISCO you would do it as follows:

Screen4View::Screen4View()
{
    HAL::getInstance()->blitFill(0, 0, 0, 480, 272, 255);
}

This will basically force the entire LCD to be filled with black color.

The prototype for this function is in HAL.cpp:

virtual void blitFill(colortype color, uint16_t x, uint16_t y, uint16_t width, uint16_t height, uint8_t alpha);

Practically, it won't make much of a difference whether you use zrrbyte's solution or mine - the performance for both solutions is similar.

That's a nice observation - Adding a Box would also simply call blitFill() with some color, but comes with a memory cost, having an additional Box object in the view. It's an edge case, but if you're extremely memory constrained and you've got a simple application that requires a single color background, this is a nice approach. — zrrbite, Jul 17 '20 at 07:27

TouchGFX widget visible on empty screen

2 Answers2