What do you want to achieve?
I’m working on a large project migrating a proprietary graphics library, let’s call it LibX, and replacing it with LVGL v8. Basically, this migration is happening in such a way that we still have to live with libX. When the application is running, some screens are rendered with libX and others with LVGL, so we need to switch between them. The way I managed to do this was by breaking the LVGL loop and deleting the objects. LibX, on the other hand, doesn’t have a loop. It simply uses the framebuffer and draws on it whenever requested.
Something like:
// Do Stuff
LibX_ShowScreenA(...);
// Do Stuff
LVGL_CreateFlowA(...);
iRunHandlerLVGL(StopCallback);
// Do Stuff
LibX_ShowScreenB(...);
Both use the framebuffer.
In the application code, whenever I need to use the screens that were migrated from LVGL, I need to call iRunHandlerLVGL(StopCallback). When I need to go back to LibX, I just need StopCallback to interrupt the LVGL loop.
This has been working relatively well. We’ve even put some things into production already. But in some scenarios, the transition doesn’t seem very smooth. Especially screens with more elements.
Is there any way to make this transition smoother?
I was wondering if it would be possible to keep LVGL always running in a thread. When in the LibX context, LVGL stops updating screens and capturing inputs, letting LibX use them, and when it needs to display screens with LVGL, it only returns the screen and input handles.
Environment
- MCU/MPU/Board: Embedded Linux with Arm
- LVGL version: v8.3.9