I have a question about screen transition with animation as below steps:
screen A display as premise.
Transit screen A to screen B with animation by using
lv_scr_load_anim(B, LV_SCR_LOAD_ANIM_FADE_ON, 500, 0, true);
※ true : for auto-delete screen A when animation has done.
In the middle of above transition animation, transit screen B to C without animation
lv_scr_load(C);
lv_obj_del(B);
Delete screen A object
lv_obj_del(A);
※Screen A is still exist because above animation has not been done.
When screen C has already displayed, everything is normal run,
but at the timing I delete screen A, application is stopped.
Could you tell me, Is there any problem transiting to another screen while screen animation is running? maybe this problem is not immediate impact until delete screen A !?
I don’t think the library currently handles this type of scenario, where you change screens using the old API while an animation from the new API is running.
As a workaround you might be able to use lv_scr_load_anim(C, LV_SCR_LOAD_ANIM_NONE, 0, 0, false);, since I believe that case is handled correctly.
@kisvegabor Would it make sense to change lv_disp_load_scr to just call lv_scr_load_anim with a time and delay of 0 internally? The latter could also be optimized to skip building an animation structure in this scenario.
Thanks for your reply soon.
I have tried your solution, and it works correctly.
But there are still a few points that I don’t understand, could you help me answer them?
※ I forgot the using LVGL version in description, it is 7.10.1
As above scenario, at step 3, instead of using lv_scr_load(C), I call lv_scr_load_anim(C, LV_SCR_LOAD_ANIM_NONE, 0, 0, false) and I realized that It will stop animation of A->B transition, then auto-delete screen A and finally transit to C
I wonder how LVGL can do auto-delete screen A although A->B animation was stoped on the way?
lv_scr_load() is an old API, is it means this API is obsolete and should not use?
In normal transition without animation, should I use lv_scr_load() or lv_scr_load_anim(screen, LV_SCR_LOAD_ANIM_NONE, 0, 0, false)
For now using lv_scr_load will be more performant, but you can’t use it while another animation is running. I am proposing to Gabor that we optimize lv_scr_load_anim internally and then use it under the hood for lv_scr_load. At that point there will be no difference, and this unexpected behavior will also be solved.
There are other internal issues here too. I even don’t know what should be the expected behavior.
Imagine a 1000ms fade anim from A->B. Immediately after that an 1000 ms B->C fade anim starts with 500 ms delay. So:
0ms: Only A is visible
10ms: B start to show up
500ms: A and B are half-half visible
510ms : A and B are half-half visible + C start to show up
750ms: B stops at 50% or already at 75%? And now are 3 screens visible at the same time?
1000ms: B anim is over, C at 50%
1500ms: only C is visible.
So some rework is clearly required here. In the above scenario, now B is instantly loaded when the delay of B->C is over.
Some queuing or so? But if we have multiple moving left, right, top, bottom screen anim at the same time it’s a little bit hard to imagine what should be where. E.g. B is is shown by scrolling A to the left and scroll in B from the right to left. After that do the same anim with C but vertically. Not impossible but seems a little bit complicated.
Personally, I’m fine with the general idea of the current behavior and I think it makes sense. There is no queue, and attempting to start a new animation results in the old one being finished immediately.
In your scenario:
500ms: The A->B animation should immediately finish and B should be fully visible on the screen. A is removed from the screen.
