Strange switching screens

I use lvgl v7.6.1
My app has some screens wich i switch using lv_scr_load(). But sometimes aftert I switch screen I can see strange behavior: library during refresh areas uses flush_cb() for each element from new screen while display buffer contains previous screen. So I see gradually drawing new elements on the top of the old elements. After that refreshes entire screen at 0,0.

Is it possible to prevent this, and use flush when all elementsof new screen ?

Is there any special configuration? To be be sure please attach your lv_conf.h and the flush_cb.

I use lvgl as a module of zephyr-rtos. So some configs made on a build-time. flush_cb() also part of zephyr-rtos. prj_conf.txt is project configuration of LVGL module. Also some of elements are png-images, to decode them I use lv_png library.
lv_conf.h (35.2 KB)
prj_conf.txt (1.7 KB)

I attached application log. To switch to another screen I use buttons (input device LV_INDEV_TYPE_BUTTON). Inside event handler added console output “click”. Also added monitor_cb() where I output to the console total time of refresh cycle. So when I clicked button on the “A” screen, appl switched to “C” screen, and I can see first refresh cycle for 786432px (full screen of 768x1024) in 181ms. But if click button on “C” screen back to “A” screen - I see a lot of writes to display small objects which ends with write of full screen (768x1024) and total time of refresh cycle is 655 ms.

log.txt (4.2 KB)

The configs seems correct.

It looks like if the screen the bg_opa = 0. Have you removed the styles of the screen or set their bg_opa?

Can you try with 2 very simple screens? Only 1-1 buttons on each, do not change styles and switch screen on button clicks.

both screens where I wounded problems are images, created with code

    obj_screen = lv_img_create(NULL, NULL);
    lv_img_set_src(obj_screen, vp_img_Bg_bmp);

For one of the screen used followed style configuration

    lv_obj_set_style_local_bg_color(obj_screen, LV_OBJ_PART_MAIN, LV_STATE_DEFAULT, LV_COLOR_BLACK);
    lv_obj_set_style_local_bg_opa(obj_screen, LV_OBJ_PART_MAIN, LV_STATE_DEFAULT, LV_OPA_COVER);

Please send a minimal code to reproduce.

What if before I use lv_scr_load(new_scr) I’ll update elements on it - hide on-off/change labels/change styles? Also lv_task_handler() and lv_scr_load() called in different threads (os - threads, not lvgl-threads).
Сould it lead to this behavior?

If you use multiple tasks for UI take look at this part of the docs: Operating system and interrupts — LVGL documentation

I added mutex lock/unlock in threads - but it can’t help.
I continued investagtion in debug mode and found following.
As I wrote before switch new screen I update elements on it. Some functions use lv_obj_invalidate() which call lv_obj_invalidate_area(). lv_obj_area_is_visible() return true for some updated elements on switched-off screen, and as far as I understand areas marked as needing updating. After that mutex unlocked, and lv_task_handler() from an another thread call _lv_disp_refr_task(), and only after refreshing areas switch to new screen.
So instead of

if(obj_scr == lv_disp_get_scr_act(disp) ||
       obj_scr == lv_disp_get_scr_prev(disp) ||
       obj_scr == lv_disp_get_layer_top(disp) ||
       obj_scr == lv_disp_get_layer_sys(disp)) {

in lv_obj_area_is_visible() I added

if(obj_scr != lv_disp_get_scr_act(disp) &&
       obj_scr != lv_disp_get_scr_prev(disp) &&
       obj_scr != lv_disp_get_layer_top(disp) &&
       obj_scr != lv_disp_get_layer_sys(disp)) {
        return false;
    }
    {

Since it is done in the lv_obj_area_is_visible() of current branch.

As far as I understand, this was the reason for another incomprehensible phenomenon - frequent (every 400 ms) updating of one of the zones on the screen (in the log of my program there is a certain object 10px width, 9px height, @ 86,101) - even if there were no changes to the objects on the screen. This frequent update is gone after the fixes.

It’s great that you have found the problem.
In v8 it’s already written with!= and &&.

A PR to the release/v7 brach would be very welcome :slight_smile:

If it still matters PR to release/v7 branch here

1 Like

Merged, thank you! :slight_smile: