“multi-instance” support is a new feature in LVGL v9 and we kept this name in the MicroPython repos to follow the lvgl’s master branch.
So, yes the multi-instance branches should be sued for now.
FYI, by “test” (and what is in the PR) I mean that, we check if the binding was generated successfully and all the major features (widget creation, event handling, animations, etc) are working well. So we don’t test whether LVGL can really do these because these are tested in LVGL’s C CI. For the bindings we need to test only whether the binding really can expose LVGL’s API.
@amirgon In the near past the multi-instance branches were working well with lvgl master, so I wonder if we can merge them to lv_micropython and lv_binding_micropython master. What do you think?
The multi-instance branch of lv_micropython and lv_binding_micropython repos are still unstable, so I think it’s early to merge these to master.
(if we don’t want to scare off people using MicroPython & LVGL, then - in my opinion - we should keep a stable version of MicroPython binding on master branch)
I’ve updated LVGL to latest (in my github fork), deployed to real devices (Lilygo T-Display and M5Core2), and have noticed 2 main problems:
There is a big performance degradation: scrolling is very-very slow, but also the overall rendering is slower when we show many LVGL objects (buttons, labels, PNG images) → the new parallel-rendering architecture needs to be optimized for speed. I’ve seen many memory operations (lv_malloc, lv_free) during drawing, but I’m still investigating it.
@kisvegabor I downloaded and compiled feat/multi-instance for the unix target. It seems to work fine with advanced_demo.py. I tried it with one of my test files and it fails with
AttributeError: ‘lv_style_t’ object has no attribute ‘set_img_recolor’
That same test file works without error and as expected under the master branch. Both the master branch and feat/multi-instance return 9, 0, dev for lv.version_major(), lv.version_minor(), lv.version_info().
Ah, that’s right. I’ll add a helper function to swap the bytes of the rendered image in the flush_cb.
I measured 10% speed up in C. Can it happen because of the PNG images? Do you see the slow down without PNG images as well?
The caching mechanism of images was improved in v9 (finally we can set the max memory to use for cache and not the number of cached images). See here. I’ve just checked that the cache definition is still not updated in MicroPython’s lv_conf.h.
Anyway, let’s stick with these temporal feat/multi-instance branches for now.
We made some updates on the API of LVGL. It mainly means just avoiding abbreviations. Due to this img was renamed to image. See the first comment here about the API related changes in v9.
The master branch on lv_micropython uses an earlier version of LVGL v9-dev (as a submodule) in which we had less large scale changes yet.
If using SDL is there any to override lv_display_create so it points to lv_sdl_window_create
maybe override lv_display_set_flush_cb and lv_display_set_draw_buffers to point to do nothing functions.
This would make it a bit easier when using SDL as a quick way to prototype. The user can just move the code over to their MCU and not need to change those things.
There no C-ish way to do that, but the idea is to change only a single function call. We already have lv_sdl_window_create but in the future we will have many built-in drivers as well. It took much longer to get here than I anticipated, but finally we are working on the first display driver.