topic Re: GUI Guider Inquiry about serious performance issues? in GUI Guider

GUI Guider Inquiry about serious performance issues?

seobi1111 — Fri, 16 Feb 2024 11:20:16 GMT

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.

Re: GUI Guider Inquiry about serious performance issues?

zongchunyu — Mon, 19 Feb 2024 06:45:34 GMT

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

Re: GUI Guider Inquiry about serious performance issues?

seobi1111 — Mon, 19 Feb 2024 09:07:02 GMT

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.

Re: GUI Guider Inquiry about serious performance issues?

Alex_Wang — Wed, 21 Feb 2024 09:56:41 GMT

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

Re: GUI Guider Inquiry about serious performance issues?

seobi1111 — Wed, 21 Feb 2024 10:52:53 GMT

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.

Re: GUI Guider Inquiry about serious performance issues?

Alex_Wang — Fri, 23 Feb 2024 02:50:35 GMT

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

Re: GUI Guider Inquiry about serious performance issues?

seobi1111 — Fri, 23 Feb 2024 03:47:15 GMT

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.

Re: GUI Guider Inquiry about serious performance issues?

Alex_Wang — Fri, 23 Feb 2024 06:21:36 GMT

Hi，@seobi1111

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

BR, Alex

Re: GUI Guider Inquiry about serious performance issues?

seobi1111 — Fri, 23 Feb 2024 06:19:37 GMT

Sent to xxxxxxx.
Please confirm.

Re: GUI Guider Inquiry about serious performance issues?

Alex_Wang — Mon, 04 Mar 2024 05:00:34 GMT

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

Re: GUI Guider Inquiry about serious performance issues?

seobi1111 — Mon, 04 Mar 2024 06:30:04 GMT

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.