I noticed, that initialization time increased on every screen addition in SLS.
Sure it will increase, but when running a test with about 30 screens, I ended up on !!!8900ms!!! initialization time on an ESP32-S3 system.
In general, what is the best practice with SLS when using that many screens? Is there a way to prioitize some screens and load others in background? Any project settings that require my attention?
Thanks a lot for your advice in advance.
Is it lv_init() that takes 8900ms or something else? Our lv_init() takes ~4ms with more screens than you’ve got, but most of our screens are temporary. Managing this does come with its own complexity though.
It ist ui_init() generated by SLS.
I had forgotten about that one - it takes ~50ms here, with around 40 temporary screens.
Generally it’s a good idea to use temporary screens (by checking the corresponding flag in SquareLine Studio inspector for the screens), so you don’t need to slowly load all screens at startup and take that much memory for them. (But temporary screens need careful handling of animations/etc. on the other hand.)
Slowdown now can also be related to the dynamic memory reallocation of the new theme-handling code, as reported by some. Meanwhile this code got converted/optimized into a better-suited linked-list variant, but if you have a slow(ish) memory, the current theme-handler code (exported if you use global colors/themes) can be one of the reasons for your slowdown. Simply deleting themes and global colors (auto-converted back to RGB) turns off exporting theme-code.
(Some profiling on your code with gprof or callgrind might shed a light on the most-used functions, they can even be i18n-related if there are many dictionary lookups.)
Thanks a lot for your suggestions.
After adding another ten screens, I am at 28450ms now.
I am puzzled and will turn off multilanguage and themes as next step.
I will also look into temporary screens. Any suggestions in handling of those would be appreciated.
Quick update:
Turning off themes or multilanguage did NOT decrease startup time.
Having plenty of screens marked “temporary” did significantly reduce startup time, but intelligent widget update handling based on settings will be required, as controller otherwise will crash.
So I will need deeper understanding on temporary screens. Once creating/init a temporary screen, will it resist and be available in background until deleted? What would be best practice to implement temporary screens handling?
Thanks a lot for your advice in advance.
Unfortunately the temporary screens don’t remain in the background but get deleted, that’s the essence of using them, to reduce memory consumption. The exported UI code opens/closes temporary screens fine, but every dynamic widget’s position/text should be recreated from variables upon reopening those screens. That’s one of the culprits among the several others, preparing screen_loaded functions for all screens in SquareLine Studio can be used to initialize those when the widgets to adjust appear. Other quirks are checking object and screen availibility with lv_obj_is_valid() before modifying it. Animation-callbacks should be deleted when the screen of their target is deleted.
(If you still want to go without temporary screens, I still suspect you have a slow memory or similar bottleneck for your actual design’s complexity. LVGL uses dynamic memory allocations for styles/etc. in the background. Maybe try playing with LV_MEM_CUSTOM settings, but not sure if memory allocation will help much in this case, just a tip.)
Thanks for clarification.
After major restructuring design to have temporary screens and initialization of elements screen loading startup is much faster.
Loading of essential screens takes about 3,5sec now. Still high, but might be acceptable.
Your system must be missconfigured. Try show setup etc.
Is there a specific version this is available at? I’m look at the flags for a screen and I have:
Thanks