fbt launch app doesn't corrctly set up draw callbacks via view_dispatch

[kbembedded]

Describe the bug.

I've done a bisect and tracked it down to 761a14e6e2ffd417a8afe2eb8dd6f24dd812f9b5

Essentially, for a couple of applications (examples below) when the application is started via ftb launch... or ufbt launch... when the flipper is on the idle/animation screen, some combination of events causes View draw callbacks registered in a view registered with a View Dispatcher to not get called. This does not appear to happen if the Flipper is not on the idle/animation screen.

What ends up happening is when a view is switched to, the draw callback is called once, and never again. Under normal circumstances it looks like view_port_draw and view_dispatcher_draw_callback are called every tick. However, when in the problem state neither of those get called either. An application not using view dispatcher and manually switching views does not appear to be affected by this.

I'd love to dig deeper in to it, but the affected commit was the huge change to application loading and is a rollup of many things. I don't know the FW that well yet and figured it would be better to open an issue and let someone else deal with it.

Reproduction

Examples of this occurring:

• Clone flipper firmware repo
• In applications_user/ clone https://github.com/kbembedded/Flipper-Zero-Game-Boy-Pokemon-Trading/tree/code-refactor as pokemon
• Build and run via fbt launch... with the flipper on the idle/animation screen.
• Once on the main menu, enter the Select pokemon submenu. On this view, pressing any of the directions does not correctly cause the image on the screen to update. But if you press a few directions, then press OK, you are sent back to the main menu with the selection set in place.
• If you back all the way out and re-launch the application, you will see normal behavior.
• This can be reproduced using ufbt launch... as well
• If the flipper is not in the idle/animation screen, the application behaves normally as well with (u)fbt launch... used to start it.

Another example is from https://github.com/jamisonderek/flipper-zero-tutorials/blob/main/ui/basic_scenes however, you will need a debugger attached and running

• Check out the whole repo
• Copy to firmware repo applications_user/ as basic_scenes and build/launch with ./fbt launch... with the Flipper on the idle/animation screen.
• Enter the Lotto Numbers view
• Set breakpoints on view_port_draw and view_dispatcher_draw and note that they never run on ticks while on this screen.
• If the application is closed and manually re-launched from the Flipper interface, and breakpoints set on the above functions, you can see them running every tick as expected.

If you repeat the above on a commit before 761a14e6e2ffd417a8afe2eb8dd6f24dd812f9b5 of the Flipper firmware, the applications run as expected.

Target

No response

Logs

I unfortunately don't know enough about the details of the View subsystem to know how to better debug this. All I can see are draw callbacks not being called, and it appears to be specifically related to the use of view_dispatcher.

Anything else?

No response

[skotopes]

There is an incorrect usage of the View:

• ViewPort draw callback is called only when Gui subsystem requires to redraw screen. It may be called at anytime or not called at all if there is no redraw requests.
• You must call ViewPort update to request gui to redraw.
• ViewDispatcher and View are implementing it under the hood, providing View model instead.
• Model update automatically issues redraw request.

[kbembedded]

Thank you for pointing that out. I apologize for taking more of your time, but I have a followup question:

Does that mean that what I described as the functional behavioral differences above, i.e. when manually starting the example applications the draw callback being called every tick, is that considered incorrect behavior from the firmware? It was pointed out to me that the behavioral differences are correlated to whether or not the Flipper runs the loading hourglass animation on application startup.

I am not sure if the described differences are unexpected behavior or if they fall under your statement of [ViewPort draw callback] may be called at anytime or not called at all if there is no redraw requests. and are simply an effect of how the application is loaded and whether or not it is intentional it is still acceptable behavior.

[skotopes]

Nope, firmware behavior is correct.

Draw calls only happens when they are requested. There is no such thing like draw call schedule.

Any active ViewPort can request draw call. Some requests from another ViewPorts may be delivered to your application.

When you starting app from RPC or CLI there are no other windows visible and that's why you don't see parasitic draw calls.

The only right way for your application to behave is to accept any draw calls at any time. And if explicit redraw needed then call view_port_update or view_commit_model.