GUI Guider Inquiry about serious performance issues?

[seobi1111]

Hello.

A serious problem occured during development with the GUI Guider.

There is an issue where operation becomes very slow when multiple widgets(e.g. buttons) are displayed in a single screen container box.

Below is the test screen and code.

[Screen Container1] : button widget 40 ea

[Screen Container2] : button widget 0 ea

[Code]

The label marked '0' is continuously increased by 1 in an infinite loop.

The label value increases very slowly in screen 1 than in screen 2.

The more widgets you add, the slower it becomes.

The application you want to develop must display data in real(RPM, km/h, etc.) with multiple widgets such as images, labels and buttons.

I've tried various improvements, but couldn't find a solution, so I'm contacting you.

If there is no way to improve, we urgently need to review other UI tools, so we would appreciate your quick reply.

[zongchunyu]

Hello,

To improve the performance of the application you mentioned. you can try the following ways:

1. Replace the 40 button widgets with one button matrix widget. this can reduce the widget number but get same effects.

2. Create another FreeRTOS task to increase and set the label value.

Best Regards

Zongchun

[seobi1111]

Hi. zongchunyu~

Thanks for your reply.

1. Replace the 40 button widgets with one button matrix widget. this can reduce the widget number but get same effects.

 => The 40 button is an example to express that placing multiple widgets slows down the process.

      I need to use not only buttons but also various widgets such as images, labels, and imgbtn.

      Therefore, changing to button matrix is not subject to review.

2. Create another FreeRTOS task to increase and set the label value.

 => I tried creating an additional task and changing the label value, but it was confirmed to be slower.

      Please give an example of adding a simple task.

[Alex_Wang]

Hi, @seobi1111 

        Hello, I tried to create a new task, and add a lot of buttons, the number ++ speed has no effect. Your code is putting the number ++ task into the Apptask task, and as the number of buttons increases this will affect the number ++ speed.

        You need to remove the number ++ from the Apptask task and put it in the new task. In fact, the main code is to create a new function and create a new task within the main function to call that function. For reference:

// Create a new function number ++
uint64_t uKm = 0;
static void TestTask(void *param)
{
	while(1)
    {
		if (guider_ui.screen_label_1 != NULL)
		{
		    lv_label_set_text_fmt(guider_ui.screen_label_1, "%01"LV_PRIu32, uKm++);
		}

        vTaskDelay(10);
    }
}
// Add a new task call function to the main function
int main(void)
{
    BaseType_t stat;

    /* Init board hardware. */
    /* attach FRO 12M to FLEXCOMM4 (debug console) */
    CLOCK_SetClkDiv(kCLOCK_DivFlexcom4Clk, 1u);
    CLOCK_AttachClk(BOARD_DEBUG_UART_CLK_ATTACH);

    /* attach FRO 12M to FLEXCOMM2 */
    CLOCK_SetClkDiv(kCLOCK_DivFlexcom2Clk, 1u);
    CLOCK_AttachClk(kFRO12M_to_FLEXCOMM2);

    CLOCK_SetClkDiv(kCLOCK_DivFlexioClk, 1u);
    CLOCK_AttachClk(kPLL0_to_FLEXIO);
    BOARD_InitBootClocks();
    BOARD_I2C_ReleaseBus();
    BOARD_InitBootPins();
    BOARD_InitDebugConsole();
    DEMO_InitUsTimer();
    
    /* Init smartdma. */
    BOARD_InitSmartDMA();

    stat = xTaskCreate(AppTask, "lvgl", configMINIMAL_STACK_SIZE + 800, NULL, tskIDLE_PRIORITY + 2, NULL);

    if (pdPASS != stat)
    {
        PRINTF("Failed to create lvgl task");
        while (1)
            ;
    }

    stat = xTaskCreate(TestTask, "test", configMINIMAL_STACK_SIZE + 1000, NULL, tskIDLE_PRIORITY + 1, NULL);

        if (pdPASS != stat)
        {
            PRINTF("Failed to create test task");
            while (1)
                ;
        }


    vTaskStartScheduler();

    for (;;)
    {
    } /* should never get here */
}

Best regards, Alex

[seobi1111]

Hi Alex_Wang

Thanks for your reply.

I tried following your guide, but nothing changed.

Rather, the number has only increased, but the speed is still slow.

Below is my code.

/*
 * Copyright 2020 NXP
 * All rights reserved.
 *
 * SPDX-License-Identifier: BSD-3-Clause
 */

#include "FreeRTOS.h"
#include "task.h"

#include "fsl_debug_console.h"
#include "lvgl_support.h"
#include "pin_mux.h"
#include "board.h"
#include "lvgl.h"
#include "gui_guider.h"
#include "events_init.h"
#include "custom.h"
#include "lvgl_demo_utils.h"
#include "lvgl_freertos.h"

#include "fsl_soc_src.h"

#include "event_groups.h"
/*******************************************************************************
 * Definitions
 ******************************************************************************/
#define B0 (1 << 0)
#define B1 (1 << 1)

/*******************************************************************************
 * Variables
 ******************************************************************************/
static volatile bool s_lvgl_initialized = false;
lv_ui guider_ui;

/*******************************************************************************
 * Prototypes
 ******************************************************************************/

#if LV_USE_LOG
static void print_cb(const char *buf)
{
    PRINTF("\r%s\n", buf);
}
#endif

static uint32_t get_idle_time_cb(void)
{
    return (getIdleTaskTime() / 1000);
}

static void reset_idle_time_cb(void)
{
    resetIdleTaskTime();
}

uint16_t uRpm = 0;
static void AppTask(void *param)
{
#if LV_USE_LOG
    lv_log_register_print_cb(print_cb);
#endif

    lv_timer_register_get_idle_cb(get_idle_time_cb);
    lv_timer_register_reset_idle_cb(reset_idle_time_cb);
    lv_port_pre_init();
    lv_init();
    lv_port_disp_init();
    lv_port_indev_init();

    s_lvgl_initialized = true;

    setup_ui(&guider_ui);
    events_init(&guider_ui);
    custom_init(&guider_ui);

    for (;;)
    {
    	lv_task_handler();
    	vTaskDelay(5);
    }
}

static void TestTask(void *param)
{
    for (;;)
    {
    	if (guider_ui.screen_label_1 != NULL)
    	{
    		lv_label_set_text_fmt(guider_ui.screen_label_1 , "%01"LV_PRIu32, uRpm++);
    	}

    	vTaskDelay(10);
    }
}

/*******************************************************************************
 * Code
 ******************************************************************************/
/*!
 * @brief Main function
 */
int main(void)
{
    BaseType_t stat;

    /* Init board hardware. */
    BOARD_ConfigMPU();
    BOARD_BootClockRUN();

    /*
     * Reset the displaymix, otherwise during debugging, the
     * debugger may not reset the display, then the behavior
     * is not right.
     */
    SRC_AssertSliceSoftwareReset(SRC, kSRC_DisplaySlice);

    BOARD_InitLpuartPins();
    BOARD_InitMipiPanelPins();
    BOARD_MIPIPanelTouch_I2C_Init();
    BOARD_InitDebugConsole();
    DEMO_InitUsTimer();

    stat = xTaskCreate(AppTask, "lvgl", configMINIMAL_STACK_SIZE + 800, NULL, tskIDLE_PRIORITY + 2, NULL);

    if (pdPASS != stat)
    {
        PRINTF("Failed to create lvgl task");
        while (1)
            ;
    }

    stat = xTaskCreate(TestTask, "test", configMINIMAL_STACK_SIZE + 1000, NULL, tskIDLE_PRIORITY + 1, NULL);

    if (pdPASS != stat)
    {
        PRINTF("Failed to create test task");
        while (1)
            ;
    }

    vTaskStartScheduler();

    for (;;)
    {
    } /* should never get here */
}

/*!
 * @brief Malloc failed hook.
 */
void vApplicationMallocFailedHook(void)
{
    PRINTF("Malloc failed. Increase the heap size.");

    for (;;)
        ;
}

/*!
 * @brief FreeRTOS tick hook.
 */
void vApplicationTickHook(void)
{
    if (s_lvgl_initialized)
    {
        lv_tick_inc(1);
    }
}

/*!
 * @brief Stack overflow hook.
 */
void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName)
{
    (void)pcTaskName;
    (void)xTask;

    for (;;)
        ;
}

Please advise.

And I am testing with MIMXRT1170-EVK.

[Alex_Wang]

Hi, @seobi1111 

        I tested it in MIMXRT1170-EVK and did not see a significant slowdown with the naked eye, please refer to the video.

        If it is convenient, please share your test results.

Best regards, Alex

[seobi1111]

Hello, Alex_Wang
Thank you very much for your active help.
I hope this issue will be resolved soon.
I am attaching my GUI Guider and MCUXpresso project.
Please test my project in your test environment.
When you touch the left or right button, cont_1 and cont_2 are switched, and the speed varies greatly depending on whether the button widget is present or not.
Please check and confirm if you have the same issue as me.

* Since large files cannot be attached, it will be sent in double-split compression.

* If you are unable to unzip the file, please provide me with an email address where I can receive the large compressed file.

[Alex_Wang]

Hi，@seobi1111 

I'm sorry, but my computer can't unzip your file. Please send to me at: xxxxxxx

BR, Alex

[seobi1111]

Sent to xxxxxxx.
Please confirm.

[Alex_Wang]

Hi, @seobi1111 

         I am very sorry to reply you so long. We have verified your code and the laber++ speed is different. We suggest that if you want to get accurate counting speed, you need to use a timer to complete it. If you only use ++ to count, it will be affected by CPU loading, because we refresh the interface through LCDIF for RT, and loading is relatively large when there are many objects in the screen.

        We have reported this problem to the development department. Now, you can try using a timer to change the speed of laber++. Hope this helps you.

Best regards, Alex

[seobi1111]

Hi, Alex_Wang.

Anyway, I wanted to inquire about today’s progress.

Even if you use a timer, won't there be a load on screen updating if there are many widgets or objects?

Even if we use a timer, we get the same results.

If you get different results from ours, please share your test video and code.

We would also appreciate it if the NXP development team would consider a solution as soon as possible.

Thanks.