TouchGFX: Performance Issues SwipeContainer with DynamicGraphs

[Julian_]

Hi all,

we're right now switching from 32F469IDISCOVERY with STM32F469NIH6 (running @180Mhz) to another display board with a STM32U5A9NJH6Q (running @160Mhz).

Our UI has one Screen with a SwipeContainer (total of 3 pages). On the second page we're using two DynamicGraphs to display a target curve and a curve with measured data (both Graphs are using a Line as Element).

During swiping the animation is very slow and laggy. Of course we can also see some performance decrease on the discovery board but on the new board it is not acceptable- therefore I'm searching for some hints how to improve this behaviour.

When the graphs are empty the animation of the swipe container is fast enought. But If both graphs are filled with data (right now we have 480 datapoints for each graph / maximum is 600 for each graph) the animation is very slow. The more datapoints are pushed to the graphs the slower the animation gets.

1) Is there a way to improve this?

2) Why the Line/Data has such an impact on the performance?

Performance

The Dynamic Graph performance will vary, depending upon the setup of the widget.

The chosen dynamic behavior impacts the performance.

• "Wrap And Clear" is a fast performing behavior because it only draws the newest data point added.
• "Wrap And Overwrite" is a fast performing behavior because it only draws the newest data point added. <- we use Wrap and overwrite
• "Scroll" is a demanding behavior, since everytime a data point is added, all the previous data points visible also need to be redrawn.

Certain graph elements will be faster to draw.

Boxes and Histogram are the fastest performing graph elements, because they do not have to read any pixel data or do any complicated calculations.

Area, Diamonds, Dots and Line <- we use Line, are CanvasWidgets and are heavily dependent on the MCU for rendering. (dots is even slower)

Hope for some hints. Thanks.

Best regards,

Julian

 

[LouisB]

Hello @Julian_ ,

The dynamic graph contains a lot of data draw on the screen, also if the canvas buffer is too little, this can lead to performance drops in some cases.
Have you tried to increase the canvas buffer ? Canvas Widgets | TouchGFX Documentation

BR,

[Julian_]

Hi Louis,

thanks for the fat response. I increased the canvas buffer size from default (might be 12000) to 32767 (as it was on the old project for the 32F469IDISCOVERY board.

The performance increased so it's way better, but not perfect. I will try to increase the canvas buffer a little bit more - is there a possibility to know/calculate what's the best value for the canvas buffer size?

Would be nice to know.

Best regards,

Julian

[LouisB]

Hello @Julian_ ,

In the link I sent you there's the paragraph below on how to find the right value for the canvas buffer.

BR,

[Julian_]

Hi @LouisB ,

in the link it is descripted how to check this in the simulator. Is there a way to check this without simulator? The simulator is not running in our project - so would be nice if we can access the information ? Maybe I can use CanvasWidgetRenderer.getMissingBufferSize() (Calculate how much memory was required by CanvasWidgets, but was unavailable) - if so where should I use this to check the Missing Buffer Size for the Graph page of the SwipeContainer?

Would be nice if you have an advice for me.

Best,

Julian

[Julian_]

@LouisB  it seems that CanvasWidgetRenderer.getMissingBufferSize() is also only available in the simulator, right?

#ifdef SIMULATOR
    /**
     * Memory reporting.
     *
     * Memory reporting can be turned on (and off) using this method. CWR will try to work
     * with the given amount of memory passed when calling setupBuffer(). If the outline of
     * the figure is too complex, this will be reported.
     *
     * "CWR requires X bytes" means that X bytes is the highest number of bytes required by
     * CWR so far, but since the size of the invalidated area and the shape of things draw
     * can influence this, this may be reported several times with a higher and higher
     * number. Leave your app running for a long time to find out what the memory
     * requirements are.
     *
     * "CWR requires X bytes (Y bytes missing)" means the same as the report above, but
     * there as was not enough memory to render the entire shape. To get around this, CWR
     * will split the shape into two separate drawings of half size. This means that less
     * memory is required, but drawing will be (somewhat)
     * slower. After you see this message all future draws will be split into smaller chunks,
     * so memory requirements might not get as high. This is followed by:
     *
     * "CWR will split draw into multiple draws due to limited memory." actually just means
     * that CWR will try to work with a smaller amount of memory.
     *
     * In general, if there is enough memory available to run the simulation and never see
     * the message "CWR will split draw ...", this is preferred. The size of the buffer
     * required will be the highest number X reported as "CWR requires X bytes". Good
     * numbers can also be around half of X.
     *
     * @param  writeUsageReport true to write report.
     *
     * @see setupBuffer
     */
    static void setWriteMemoryUsageReport(bool writeUsageReport);

    /**
     * Gets write memory usage report flag.
     *
     * @return true if it CWR writes memory reports, false if not.
     */
    static bool getWriteMemoryUsageReport();

    /// @cond
    /**
     * Called after a shape (Circle, Line, etc.) has been drawn to keep track of the memory
     * requirements of CanvasWidgets.
     *
     * @param  used Number of Cell objects used from the dedicated buffer.
     */
    static void numCellsUsed(unsigned used);

    /**
     * Called after a shape (Circle, Line, etc.) has been drawn to keep track of the memory
     * requirements of CanvasWidgets.
     *
     * @param  missing Number of Cell objects required, but not available.
     */
    static void numCellsMissing(unsigned missing);
    /// @endcond

    /**
     * Calculate how much memory has been required by CanvasWidgets. This can be used to
     * fine tune the size of the buffer passed to CanvasWidgetRenderer upon initialization.
     *
     * @return The number of bytes required.
     */
    static unsigned getUsedBufferSize();

    /**
     * Calculate how much memory was required by CanvasWidgets, but was unavailable. If the
     * value returned is greater than 0 it means the This can be used to fine tune the size
     * of the buffer passed to CanvasWidgetRenderer upon initialization.
     *
     * @return The number of bytes required.
     */
    static unsigned getMissingBufferSize();
#endif

[Julian_]

@LouisB  any updates on this issue? Thanks 

[LouisB]

Hello @Julian_ ,

We dont have a way to do so on then target but you can create a sim project and import your gui to check how big your buffer size as to be .

BR,

[Julian_]

@LouisB  I tested the GUI in a simulator project, thanks for this hint. So the CWR requires 52552 bytes. Therefore I set the Canvas Buffer Size in our project to 54000 bytes. But the second page of our swipe container is still a little bit laggy. Is there another way to improve this behaviour? 

We use STM32U5A9NJH6Q (running @160Mhz). Are there some settings (hardware accelerators e.g.) which can be set?

Best regards,

Julian