v8.2 discussion

[kisvegabor]

v8.1 is released so I open this issue to plan v8.2. In order really have a "Planning phase" for the next release I'm about to leave this issue open until 31 December and focus on implementation after that.

I add my current ideas here (see explanation in the next comment), please comment if you also have some features ideas in mind or share your opinion about the planned features.

Rendering

• Abstract render layer More flexible custom drawing interface #2733
• Widgets to image buffer
• 18/24 bit color format support

Features

• Scenes
• Add/Subtract/exclusive mask types arc obj:color display error when color opa was used #2668 (postponed for the next release)
• Style components
• Overflow:visible e7ac0e4
• Hover
• More grid features

Others

• New drivers architecture New driver architecture #2720
• Markup language Markup Language for LVGL #2428
• Unit tests Writing unit tests for core widgets #2337
• Fix scripts (postponed until there is real need for complex backporting)
• Release scripts
• SVG support
• Platform independent benchmarking
• ffmpeg support add ffmpeg decoder to extra/libs #2805
• font fallback support Supports Freetype fonts in SDL Driver #2796
• add monkey test feat(others) add monkey test. #2885
• add gradient dithering support Gradient dithering #2872
• add cmsis-pack support feat: add cmsis-pack for lvgl #2993
• add lv_gridnav Add grid navigation feature #2911

[kisvegabor]

The initial list and the features ideas are not written into stone, please tell what you think about them.

Fix/Release scripts

IMO it has the highest priority. I meant these:

• a CI action to merge commits with fix* message to staging/v8.* branches
• a CI or script to merge staging/v8.* to release/v8.* periodically or triggered manually
• add CI to port to automatically update submodules and conf files and minor and patch releases
• add a simple build CI test to the port projects

Widgets to image buffer

Make possible to buffer widgets with all children into a single image to

• speed up rendering at the cost of memory usage
• allow transformation on any widgets (rotate, scale)

Scenes

It's a brand new concept about how a UI can be managed. It's a very simple but very powerful thing. Each widget has an int scene_active field and there is an lv_obj_set_scene(obj, secene_id) function which sends LV_EVENT_SCENE_UNLOAD, saves the scene_id and sends LV_EVENT_SCENE_LOAD to the widget. In other words, the scenes can be considered as "states" of the widget (I do NOT mean pressed, focused, etc style states here).

Use cases:

• There is a parent that can display 3 types of content, each is considered a scene. On scene load/unload you can hide/unhide, fade, etc between the possible contents
• There is a screen with "error" and "normal" scenes: on error, some styles are changed, and an error message is displayed. On "normal" these are reverted.
• A list has 2 scenes: hidden, visible. On scene load instead of hiding/unhiding, any complex animation can be started.

The gist is, this way the widgets encapsulate their scenes and there is a uniform API for changing scenes. As the current scene is saved it can be automatically unloaded. Without this feature, the user needed to keep track of the current state to know what to unload, but now it'd be backed into the widgets.

Add/Subtract/exclusive mask types

Now the masks of LVGL can only subtract from an 0xff filled mask. It'd be great to allow "building back" parts too.

Style components

Right now it's a little bit cumbersome to manage differently looking versions of the same widget type. E.g. button, error button, warning button, border only button, border only error button, rounded button, rounded error button, etc. To manage it effectively there should be btn, btn_border_only, btn_rounded, btn_error, btn_warning styles. The combination of these styles needs to be added manually to the created buttons. It's possible to create btn_error_create() and similar functions but it's also cumbersome. If the "role" of the button changes meanwhile, it's also hard to manage now (i.e. remove styles and add new ones). The idea to solve it looks like this:

uint32_t ERROR_BTN_ROUNDED = lv_component_create_from(LV_COMPONENT_BTN);
lv_component_add_style(ERROR_BTN_ROUNDED, &error_btn_style, LV_PART_MAIN);
lv_component_add_style(ERROR_BTN_ROUNDED, &rounded_btn_style, LV_PART_MAIN);

lv_obj_t * btn = lv_btn_create(parent);
lv_obj_set_component_type(btn, ERROR_BTN_ROUNDED);

lv_obj_set_component_type can be called any time to change the type and ERROR_BTN_ROUNDED can be updated anytime too, and all objects will be updated.

The implementation is quite simple: If functions like lv_obj_style_get_bg_color don't find a style on the object, they check the styles assigned to the component ID too.
It will save memory and give more performance because the styles with the same selector can be merged in ERROR_BTN_ROUNDED and only the component ID needs to be saved in the object, instead of many styles.

Overflow:visible

Same as in HTML

Hover

Same as in HTML

More grid features

I'm specifically thinking about repeat(auto-fill, minmax( <value> px, 1fr)) but ideas are welcome

SVG support

See thorvg/thorvg#1014

[lishaoenxm]

@kisvegabor I've created a new issue #2800. Could it be added in this version?

[guoweilkd]

Modify qrCode lv_qrcode_delete() interface, replace it with lv_obj_del().In other words, rewrite Qrcode using obj template.

[kisvegabor]

@lishaoenxm
I'll comment in the opened issue.

@guoweilkd It's quite straightforward, so I've just updated the qr code widget. See 318edd8

[embeddedt]

Sorry for the delay in replying here. Here are my thoughts:

a CI action to merge commits with fix* message to staging/v8.* branches

I think it might be safer to check for the word "backport" in the commit description, otherwise the CI will end up cherry-picking fixes for a v8.2 feature into the v8.0 and v8.1 branches, which is not what we want.

add CI to port to automatically update submodules and conf files and minor and patch releases

Are we moving lv_drivers into lvgl for v8.2? That would allow us to have only a single submodule per port, which is ideal, otherwise we have to keep the two repositories working with each other.

Style components

It seems to me that all that is needed here is a way of linking styles to a parent style. This is what I'm envisioning:

static lv_style_t btn, btn_rounded, btn_warning, btn_error;

static lv_style_t error_btn_component;

lv_style_init(&error_btn_component);
lv_style_add_child(&error_btn_component, &btn_rounded);
lv_style_add_child(&error_btn_component, &btn_error);

Now error_btn_component can be used just like any other style, but has no properties of its own.

[kisvegabor]

No problem 🙂

I think it might be safer to check for the word "backport" in the commit description, otherwise the CI will end up cherry-picking fixes for a v8.2 feature into the v8.0 and v8.1 branches, which is not what we want.

True, although it can happen that the part being fixed already changed in v8.2. But, I agree "backport" is safer and probably will result in fewer issues.

Are we moving lv_drivers into lvgl for v8.2?

I think we should.

It seems to me that all that is needed here is a way of linking styles to a parent style. This is what I'm envisioning:

As styles don't store part and state e.g. a complete slider can't be described this way where there are main, indicator, and knob parts with any combination of states.

[C47D]

18/24 bit color format support

How hard could it be to add this feature? I'm interested in helping out with this one.

Should we also consider gray scale support?

New drivers architecture New driver architecture #2720

I'm also working on this, we had a couple of really busy weeks at work, I'm continuing with the new drivers architecture next weekend.

[kisvegabor]

How hard could it be to add this feature? I'm interested in helping out with this one.

I suggest waiting a little with it. We started to work on abstracting the drawing enginesand therefore the all drawing parts will be hugely refactored and rewritten. So it should be added once the architecture is stabilized to avoid complicated merging.

I'm also working on this, we had a couple of really busy weeks at work, I'm continuing with the new drivers architecture next weekend.

Awesome! It might be also related to the abstraction of drawing. See #2803 (comment)

[C47D]

I suggest waiting a little with it. We started to work on abstracting the drawing engines and therefore the all drawing parts will be hugely refactored and rewritten. So it should be added once the architecture is stabilized to avoid complicated merging.

Sounds fair, I will focus on the drivers.

[puzrin]

Scenes

It's a brand new concept about how a UI can be managed. It's a very simple but very powerful thing.

IMO this looks like mixture of CSS cascading & transforms animation. I would implement more classic features instead of invent new ones.

Style components

Right now it's a little bit cumbersome to manage differently looking versions of the same widget type. E.g. button, error button, warning button, border only button, border only error button, rounded button, rounded error button, etc.

I don't understand the problem. https://getbootstrap.com/docs/5.1/components/buttons/ twbs is ok with mixins.

If you need syntax sugar - leave it to CPP wrapper, instead of balloon C api. It's normal to add multiple styles (modifiers) to widget.

Hover

That's very expensive thing & not available on touch interfaces. IMO added value does not worth efforts. I'd suggest to postpone that as much as possible.

Markup language

IMO that's standalone project, described as "GUI creator tool with code generator". I'm skeptic about inventig/promoting new languages. Sugar can be partially solved via CPP wrapper. And visual gui builder is usually faster to create with js/html (electron and other).

Anyway, i'd prefer this thing separate from lvgl core. It may take too much efforts and slow down other development.

---

Also, it would be nice to temporary pause with adding new features & focus on pending tails - true RGBA support in styles, benchmarks infrastructure, CPP wrapper and so on.

[kisvegabor]

IMO this looks like mixture of CSS cascading & transforms animation. I would implement more classic features instead of invent new ones.

It's more than that and it's new only in LVGL. It's inspired by QT. See here.
It helps to make otherwise public states private and encapsulate them into a component resulting in a much-much cleaner implementation. The transition can be part of it, but it's "just" a tool to organize your UI in a much cleaner way.

I don't understand the problem. https://getbootstrap.com/docs/5.1/components/buttons/ twbs is ok with mixins.

It's possible but not convenient. E.g. a React button component is much more powerful where the component's style and logic are encapsulated into one object. My suggestion is not about logic only styles though.

If you need syntax sugar - leave it to CPP wrapper, instead of balloon C api. It's normal to add multiple styles (modifiers) to widget.

The problem came up while I was working on several UI projects. It's just tedious to manage styles as they are now. And if it was inconvenient for me, I suppose it's problematic for others too.

Of course, the idea can be polished, I just wanted to raise the topic and a possible implementation direction.

That's very expensive thing & not available on touch interfaces. IMO added value does not worth efforts. I'd suggest to postpone that as much as possible.

I'm personally interested in it because we are planning to support desktop app development too with EdgeLine so, it will come in handy. It needs to be designed in a way to not be expensive. 🙂

IMO that's standalone project, described as "GUI creator tool with code generator". I'm skeptic about inventig/promoting new languages. Sugar can be partially solved via CPP wrapper. And visual gui builder is usually faster to create with js/html (electron and other).

I consider having a markup language very important. I can't mention exact use cases due to NDAs but the need for a platform independent textual UI description came from many sources. It's will also help to find illogical parts in LVGL's UI, and clean it up as much as possible.

Also, it would be nice to temporary pause with adding new features & focus on pending tails - true RGBA support in styles, benchmarks infrastructure, CPP wrapper and so on.

RGBA, would be also a new feature. 🙂 I don't consider this as high priority task as it just joins to properties into one (color+opa). Cpp wrapper is on its way, but the development slowed down a little in the past month.
Benchmarking would be great, but some contribution would be also great with it. I add it to the list

[embeddedt]

Let's discuss the topic of managing old & new releases.

I think what we are thinking of right now (assuming 8.2 is the next release) is the following:

• master is the most bleeding-edge branch and has new features, bugfixes, etc.
• staging/v8.2 is identical to master.
• staging/v8.0 and staging/v8.1 accumulate any backported bugfixes from master.
• At release time, release/v8.0 is fast-forwarded to staging/v8.0, and the same for v8.1.

@kisvegabor You and I had discussed before the idea of requiring every commit to master to be a PR with approval.

This could work for automating backporting as well, as I could make an action which tries to backport to a specific branch when someone with appropriate privileges writes a comment like "@lvgl-bot backport v8.0" in the PR.

However, it means that every commit (including simple ones like these) would need a PR opened. I suppose it would ensure that CI passes on master all the time, so maybe it's a good step?

[kisvegabor]

Meanwhile, I was thinking about if it's really worse the effort to establish a complex backporting system. After v8.0 was released I manually backported some fixes but not that much. As I haven't heard complaints about bugs in v8.0. What if we say that if someone reports a problem in v8.0 (or an older release) we manually fix that problem. Seemingly there won't be too many cases.

We can find a proper solution if there is a real need for massive backporting (maybe never 🙂 )

What do you think?

[embeddedt]

True. The majority of the backporting only tends to be needed across major version boundaries, because a decent majority of users will upgrade to the latest 8.x release if asked.

[kisvegabor]

Great! :)

The question of a good release script is still open. I've tried to do it for v7 but wasn't confident with it at all. I always run the Python script with a debugger because it always has some problems...

For v8 IMO the requirements are:

• updated version number in a few files
• update CHANGELOG
• push a tag
• on minor release: create a new branch release/v8.x
• on patch release: merge to the related branch
• also update lv_demos and lv_drivers in a similar way (the driver will be part of lvgl later)
• create a blog post from the changelog
• trigger update on other projects (lv_port_...)

[xiaoxiang781216]

Is it possible to merge lv_demos into lvgl git too? The demo is very useful to verify the porting and performance.

[kisvegabor]

Is it possible to merge lv_demos into lvgl git too? The demo is very useful to verify the porting and performance.

With this, the repo structure would be very clear. My only concern is that it'd significantly increase the repo size due to the many assets. lvgl is now 40MB, lv_demos is 65MB. With drivers and other stuff, we could easily reach 150-200 MB. It's not the end of the world, but something that's worth discussing.

[xiaoxiang781216]

Yes, but compare with today's disk capacity and network bandwidth, most developer will more enjoy the convenience.:)

[kisvegabor]

I agree. This way LVGL core, 3rd party lib, example, demo, and driver would be in one place. As part of the CI tests, we could easily un the stress demo for a while too.

[mysterywolf]

Is that possable to add LV_MEMCPY_CUSTOM and LV_MEMSET_CUSTOM to let users or OS to re-implement lv_memcpy and lv_memset by themselves, just like LV_SPRINTF_CUSTOM? RT-Thread has rt_memset and rt_memcpy in assembly language, which is faster than lv_memcpy and memcpy(no matter under GCC or Keil), and to let users to accelerate the drawing and plotting speed.

[kisvegabor]

Could we rather integrate the faster versions into LVGL? 😄

Can you give a link to your implementation?

[mysterywolf]

Yes. of course, this is one of the RT-Thread software packages. It's for Cortex-M. But I didn't translate the readme to English yet. 😅https://github.com/mysterywolf/rt_memcpy_cm

[kisvegabor]

But I didn't translate the readme to English yet.

No problem, Google Translate kindly translated it 🙂

Copy 10,000 bytes 10,000 times in keil environment
rt_memcpy is 1261ms
This compilation version is 883ms
C ​library memcpy is 906ms

Do you still have this test environment? If so could you try LVGL's memcpy?

[mysterywolf]

I retest under GCC Keil and IAR, and here is the result:😄

copy 10,000 bytes for 100,000 times (@STM32L745)

Time Cost (Unit: ms)	Keil-MDK (-O0)	GCC (-O0)	IAR(-O0)
rt_memcpy (assembly language)	8819ms	7254ms	7227ms
lv_memcpy	17406ms	47879ms	16951ms
memcpy (C Standard Library)	9073ms	6940ms	10242ms

[amirgon]

@mysterywolf - Why would you do any performance measurement with -O0 ???

[mysterywolf]

@mysterywolf - Why would you do any performance measurement with -O0 ???

To test the worst case. I want to measure the performance of different memcpy version without compiler's help. I will test the -O2 case if you want.

[amirgon]

To test the worst case. I want to measure the performance of different memcpy version without help compiler's help. I will test the -O2 case if you want.

Comparing performance with -O0 is meaningless. The compiler makes no effort to achieve performance.
Showing that one compiler gives better performance than the other with -O0 does not prove anything. The results could be opposite with -O2 or -O3.

[mysterywolf]

Done. Here is the -O2 result.

Time Cost (Unit: ms)	Keil-MDK (-O2)	GCC (-O2)	IAR(-O2)
rt_memcpy (assembly language)	8806ms	7212ms	7224ms
lv_memcpy	9510ms	8727ms	11056ms
memcpy (C Standard Library)	9063ms	6894ms	10237ms

[embeddedt]

@amirgon I'm not sure that optimization matters for something simple like a memcpy implementation. It makes sense for higher-level code, but memcpy is really just two pointers being incremented, dereferenced, and assigned. It tends to be sped up more by manual tricks like copying words instead of bytes. (edit: didn't notice the 50 seconds for lv_memcpy at the time of writing)

@mysterywolf Thanks for these measurements.

• I wonder why Keil is so much slower than the other two compilers when rt_memcpy isn't even written in C.
• I suspect the only reason GCC/Newlib's implementation wins is because I've found in the past that it's not entirely compatible with all possible use cases of memcpy. It speeds up copying with uint64_t and uint32_t but does not check for alignment first, so it will often crash when pointers are unaligned.

In general lv_memcpy seems to be reasonably performant and has the advantage of being 100% portable. However, I see nothing wrong with offering an option to use a custom memcpy implementation.

[kisvegabor]

By the way, do you think we can include lv_fragment too?

I'm on it. 🙂 I'll try my best to review it tomorrow.

---

Cmake and RT-Thread are moved to env_support.

@brgl
We are about releasing v8.2 at the end of January. In that release can we move the zephyr folder into env_support?

[GorgonMeducer]

@kisvegabor cmsis-pack is moved to env_support as planned.
#3026

[GorgonMeducer]

@kisvegabor it is close to the end of Jan. When do we release the 8.2.0？

[kisvegabor]

@GorgonMeducer
I wanted to wait as long as possible to fix issues that come up for EdgeLine. The very last day is Monday, so I'm planning the release on Monday.

[GorgonMeducer]

@kisvegabor OK, then I can release cmsis-pack v1.0.0 after Monday.
By the way, if there is any chance that the LVGL CMSIS-Pack is listed in pack-installer by default, are you happy about that?
According to the alphabet order, LVGL will be listed next to lwIP.

[kisvegabor]

OK, then I can release cmsis-pack v1.0.0 after Monday.

If you tell me what to steps are required I can ensure to have cmsis-pack v1.0.0 included in LVGL v8.2 release (and not created after it).

By the way, if there is any chance that the LVGL CMSIS-Pack is listed in pack-installer by default, are you happy about that?

Do you mean here? If so, of course, it'd be more than amazing to list LVGL on ARMs site 🙂 Is there anything I/we shall do to have LVGL listed?

[GorgonMeducer]

@kisvegabor If we want to include the cmsis-pack as part of the v8.2.0 release, please tell me when is the "last minute" to generate a cmsis-pack.

Do you mean here? If so, of course, it'd be more than amazing to list LVGL on ARMs site 🙂 Is there anything I/we shall do to have LVGL listed?

Big YES and also inside pack-installer. The only thing LVGL has to do is make sure don't change the location of LVGL.lvgl.pdsc once LVGL is listed. So if you want to change the location, do it now before I make the listing request to the KEIL team.

[kisvegabor]

Big YES and also inside pack-installer.

Amazing!

The only thing LVGL has to do is make sure don't change the location of LVGL.lvgl.pdsc once LVGL is listed.

Seems doable. 🙂

[GorgonMeducer]

@kisvegabor
cmsis pack v1.0.0 is ready for LVGL v8.2.0 release
#3062

If you have no objection, this version of the lvgl cmsis pack will be listed on the Arm website.

[kisvegabor]

Amazing, thank you! I merge it and start to to prepare the release now.

If you have no objection, this version of the lvgl cmsis pack will be listed on the Arm website.

Perfect!

[kisvegabor]

v8.2 is released!

@embeddedt I forgot that what shall we do to add v8.2. to the drop-down in the docs?

@tore-espressif There was an API token issue while pushing to the ESP component repo. Do you know how shall we fix it?

[embeddedt]

@kisvegabor This is all that should be needed, for future reference: lvgl/docs@9c54a49

[tore-espressif]

There was an API token issue while pushing to the ESP component repo. Do you know how shall we fix it?

In September 2021 I send you an API token that should be added to secrets of this repo under name ESP_IDF_COMPONENT_API_TOKEN. Did you add it? If yes, please try re-running the job (we had 30minutes down-time of our servers today...)

[embeddedt]

I see the secret in the list so I'll rerun the workflow.

[embeddedt]

@tore-espressif It still failed, but there is definitely a secret named ESP_IDF_COMPONENT_API_TOKEN. Maybe the parameter name needs to be changed here? I notice it uses whatever version of the action is on master instead of a specific version.

[tore-espressif]

@embeddedt thanks for quick response. From https://github.com/lvgl/lvgl/runs/5006767183?check_suite_focus=true#step:4:5 it seems that for some reason the api_token is not passed to the job... it usually happens when the secret is empty (?).

Anyway, I'm sending @kisvegabor new token to his email.
I double checked everything else, so I'm sure it will pass with the new token :)

[kisvegabor]

The ESP component issue is resolved, due the support from @tore-espressif. Thank you% 🙂

[GorgonMeducer]

LVGL is listed on the KEIL website and will be sync-up to the arm website later.

https://www.keil.com/dd2/pack/

[kisvegabor]

Amazing, thank you very much!

I've shared it on LinkedIn.

[lvgl-bot]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[kisvegabor]

As v8.2 is released I close this issue will open a new one for v8.3 soon.

[Frogomeli]

Hi, it's normal that the lib on PlatformIO is still at 8.1 ?
Thanks

https://registry.platformio.org/libraries/lvgl/lvgl/versions

[kisvegabor]

Hi,

I've just updated it. Should be available soon.