cancel
Showing results for 
Search instead for 
Did you mean: 

TouchGFX Performance Issues with Nested Containers and Graphs

nonoriri
Associate III

I'm developing a UI on STM32H750 using TouchGFX with a 1024x768 display. I'm experiencing significant performance issues with touch responsiveness when displaying graphs.

My UI Structure:

nonoriri_0-1744699287018.png

  1. Base screen (screen1) with a menu button
  2. When menu button is pressed, a menu container is displayed on top
  3. The menu container has a graph button which opens a graph container that overlays on top
  4. The graph display uses a CacheableContainer with multiple static graphs

The Problem:

When the graph is displayed, touch response becomes extremely slow. I've used CacheableContainer which helped slightly, but issues persist.

In the simulator, I discovered that during every tick, the entire screen (full rect 0,0,1024,768) is being redrawn unnecessarily. The CPU usage spikes when the graph is displayed.

Here's the call stack when debugging:

#0 0x005d3da7 in touchgfx::CacheableContainer::setupDrawChain(touchgfx::Rect const&, touchgfx::Drawable**) ()
#1 0x005d3aa0 in touchgfx::Container::setupDrawChain(touchgfx::Rect const&, touchgfx::Drawable**) ()
#2 0x005d3aa0 in touchgfx::Container::setupDrawChain(touchgfx::Rect const&, touchgfx::Drawable**) ()
#3 0x005d3aa0 in touchgfx::Container::setupDrawChain(touchgfx::Rect const&, touchgfx::Drawable**) ()
#4 0x005ec7fc in touchgfx::Screen::startSMOC(touchgfx::Rect const&) ()
#5 0x005ec6b1 in touchgfx::Screen::draw(touchgfx::Rect&) ()
#6 0x005e8b7a in touchgfx::Application::draw(touchgfx::Rect&) ()
#7 0x005eacad in touchgfx::Application::drawCachedAreas() ()
#8 0x005d4c0a in touchgfx::HAL::tick() ()
#9 0x00716f06 in touchgfx::HAL::backPorchExited (
this=0x810120 <touchgfx::getHAL<touchgfx::HALSDL2>(touchgfx::DMA_Interface&, touchgfx::LCD&, touchgfx::TouchController&, short, short)::hal>)
at ../Middlewares/ST/touchgfx/framework/include/touchgfx/hal/HAL.hpp:641
#10 0x005cf030 in touchgfx::HALSDL2::taskEntry (
this=0x810120 <touchgfx::getHAL<touchgfx::HALSDL2>(touchgfx::DMA_Interface&, touchgfx::LCD&, touchgfx::TouchController&, short, short)::hal>)
at ../Middlewares/ST/touchgfx/framework/source/platform/hal/simulator/sdl2/HALSDL2.cpp:755
#11 0x005d1213 in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0, lpCmdLine=0xa9329de "", nCmdShow=10) at

Further Details:

  • The drawing process is redrawing screen1, menu container, and graph container in sequence during each tick
  • The graph only needs to update every 10+ seconds, not on every frame
  • All this unnecessary redrawing is causing significant performance overhead

Question:

Is there a more efficient way to handle drawing in this scenario? How can I prevent the entire screen redraw on every tick when only small portions need updating?


Would you like me to modify anything specific in this translation?

1 ACCEPTED SOLUTION

Accepted Solutions

Is your frame buffer memory cached?
Is the background an image or a rectangle object? Loading a rectangle is faster than an image.
Perhaps 1 idea is to have the background have a cutout (4 rectangles) so it doesn't need to update the background.

Kudo posts if you have the same problem and kudo replies if the solution works.
Click "Accept as Solution" if a reply solved your problem. If no solution was posted please answer with your own.

View solution in original post

2 REPLIES 2

Is your frame buffer memory cached?
Is the background an image or a rectangle object? Loading a rectangle is faster than an image.
Perhaps 1 idea is to have the background have a cutout (4 rectangles) so it doesn't need to update the background.

Kudo posts if you have the same problem and kudo replies if the solution works.
Click "Accept as Solution" if a reply solved your problem. If no solution was posted please answer with your own.

Thank you.
The problem with my program was that unnecessary invalidate() calls were occurring every time.
After fixing it so that hidden parts are not refreshed, the performance improved.
Thank you for your kind answer.