Skip to main content
Associate II
April 15, 2025
Solved

TouchGFX Performance Issues with Nested Containers and Graphs

  • April 15, 2025
  • 1 reply
  • 571 views

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?

Best answer by unsigned_char_array

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.

1 reply

Lead II
April 15, 2025

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."
nonoririAuthor
Associate II
April 17, 2025

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.