Some observations of migrating from v7 and v8

I have a few (unrelated to each other) observations to share as I attempt to migrate to V8, and am not sure where to place them, so for now I’ll post to the forum unless advised otherwise:

colorwheel on a tab in a tabview: dragging the knob also attempts to drag the tab too, simultaneously! This can be prevented with lv_obj_clear_flag(wheel, LV_OBJ_FLAG_SCROLL_CHAIN) but I raise this here as this doesn’t seem like desirable default behavior

Message box modal: This is a welcome feature; however, it is created as modal on lv_scr_act(). This doesn’t cover objects on the top layer, which I use and assume others do for the purpose stated in the docs, such as for objects visible across screens

Memory footprint: What is the expectation regarding LVGL memory use for v8, vs. v7? I am using a Teensy 4.1, which has a healthy amount of memory but my app under v7 was pushing it. Directly porting to v8 seems to increase this. I saw approx 137k usage under v7 with the material theme. Under v8, this jumps to 150k with the basic theme and 175k with the default theme. I have reviewed lv_conf.h to check some obvious configuration items are set appropriately (for example LV_USE_LARGE_COORD 0) and nothing stands out

lv_mem_monitor: Can you bring back max_used? In the memory constrained environment of embedded development, the high water mark is just as important as the current usage level, too

auto_realign: Perhaps the one area I’m not convinced is an ‘upgrade’, although I’m sure there are good reasons. This seems to only work if the object is aligned relative to it’s parent? But I have many instances where objects are in a sibling relationship but need to align to each other; say when a labels text shrinks of grows, the sibling next to it needs to budge over a bit. auto_realign took care of this, but now it seems I need to explicitly code for this, also moving some objects to the global scope to allow the reference for align?

themes: I don’t know if it’s even possible for you to preserve themes from release to release, but I’d encourage you to do so. I am sure I am typical of many users who pick a theme that best suits their need, and then run with that with some additional styling, as needed. The thing is, that defines the look and feel of the UI and also the spacing of objects, given the differences in padding, sizes, etc. Moving to v8 and the loss of the material theme means a significant difference in the look and feel of my app, and lots of minor glitches from a spacing/sizing point of view.

Documentation: I found a few areas where the v8 docs haven’t been updated at all, or only partially, and that has made migration a little frustrating (File System is one area that comes to mind) I’d urge a more robust documentation update and review process if you can. You can use all the time you save by not providing any detailed migration documentation of what changed, etc to focus on the main docs :slight_smile:

Finally, I just want to say thanks for all you have done here! I have concentrated on pure migration from v7 to v8 at first (VSCode initially reported 1k+ issues when I switched the library from v7 to v8!) so I have yet to embrace some of the new features, but some look very helpful (event callbacks per event, user data on events, etc). I have mostly completed the functional migration, or have an idea on how to adjust the remaining elements - mostly overall styling and configuring of charts, etc. Performance feels just as snappy and if you can help with the increased memory utilization, I can call it a keeper!

Thanks for the feedback. :slightly_smiling_face:

I’ve tried to address each of the concerns below.

We are aware of some bugs with draggable objects on scrollable objects, and are discussing the best approach to fixing these issues.

I think you can work around this with one of two methods:

  • Disable the feature and create your own modal background (the v7 approach).
  • This is untested, but I think lv_obj_set_parent(lv_obj_get_parent(msgbox), lv_layer_top()); should work to move the message box to the top layer.

v8 definitely uses more, at least from my experience. I’m hoping there will be some optimizations done in minor releases. @kisvegabor did mention though that LVGL is more commonly used on microcontrollers where the increased RAM is less of an issue, so I suspect this is not the highest priority. I’d also love to see reduced RAM though.

Out of interest, what is the composition of your app in terms of widgets used, etc.?

This was probably dropped when we switched from a custom heap implementation to TLSF, which I don’t think has the feature. Technically speaking, you can implement it yourself by tracking the highest value you’ve seen from lv_mem_monitor. I see nothing wrong with adding it back to LVGL itself though.

I haven’t used auto_realign much in v7 or v8 so I’m not the most qualified to comment on it, but with v8, we are moving more towards the widget model used by HTML/CSS. This means less manual positioning/alignment and more use of layouts like flexbox and grid.

It seems that the pattern for the last 2 major releases has been that a fresh theme is released each time. It’s definitely possible to preserve the theme even after the style system changes, but I’m not sure if this is a direction @kisvegabor wants to go in.

I’m working on a new project, did start some weeks ago with V7. LVGL is only a small portion of it.
Was thinking to migrate to V8 … good chance to run in unexpected trouble?
Then I’m running out of time.
Any recommendation? Up to now I’m happy with V7

In my opinion, if you have an existing project on v7 and you want the most documentation and stability, stick with that.

Thanks for the feedback! I’ve fixed some of the mentioned issues and added some comments to complement @embeddedt’s thoughts.

It’s really unexpected as default. I’ve fixed it.

You are also right about this. I consider it rather a bug instead of a new feature so I also fixed it in master.

Have you disabled LV_USE_ASSERT_STYLE? If you send your lv_conf.h I can take look.
Can you run nm or a similar tool to analyze the RAM usage?

I suggest using a grid to replace auto_realign. It’s much more versatile and flexible.

I haven’t considered theme changes as an issue so far but you are right. It’d be better to keep them to aid migration to the new major version. I’ll keep it in mind but can’t promise this theme will be kept for multiple major releases.

Please list those parts and I’ll take care of updating them.
I’ve just updated the documentation of the file system part.

1 Like

I’m not sure if nm will help, as most of LVGL’s allocations tend to be on the heap.

True, but I just realized the mentioned 137 kB memory usage probably meant flash usage, not RAM.

:slight_smile: Actually it is RAM. I’m trading memory for performance when switching screens, creating the screens once at startup and holding in RAM vs creating/destorying on the fly. The Teensy 4.1 has 512Kb TCM, an additional 512Kb of RAM and I’ve also got 16Mb PSRAM soldered on so it all sort of squeezes in there.

Thanks for the fixes above. As for RAM utilization - right now, I’m concentrating on a straight functional migration to get it running under v8, vs. optimal v8 code utilization. I have brought the RAM overhead down a little - in v7 I was using lv_obj_allocate_ext_attr to store additional data with objects that had a shared event handler. Initially, for faster migration to v8, I redefined this method to use an objects user_data as a quick way to migrate over, no code changes required in my code base. I have subsequently made the changes to send user data via the new event handler feature, enabling me to set LV_USE_USER_DATA to zero in lv_conf.h. This saved around 7k. I’ll report back as I make changes to use v8 more effiiciently.

One other potential bug / me doing something wrong:

I have an lv_table displayed that I periodically update cells with lv_table_set_cell_value_fmt or lv_table_set_cell_value. Under v7 the display refreshed without issue, but it doesn’t update the display on v8.0.0. I noticed that tapping anywhere on the table triggered a refresh; so I added lv_obj_invalidate(table) to my update code as a workaround, for now, which triggers a display update correctly.

Thanks again!

1 Like

V8 documentation updates needed:

Base Object - Image showing align types refers to “IN TOP LEFT”, etc for all the inside alignments, but the “IN” designator was dropped from these align types enums

Layers - “Bring to the foreground” refers to lv_obj_set_top as an option, but that has been removed

File System - In the API section, this appears to be the signatures for v7 for lv_fs_open and the others, not v8. I haven’t checked all the parameter descriptions, but whence was added to lv_fs_seek, but not described in the parameter section

Does it really take so much time to create the widgets?

lv_obj_invalidate was really missing I fixed it.

All should be fixed.