Separate the rendering and widgets

[AlixANNERAUD]

Introduce the problem

It would be good to be able to get rid of the rendering part when needed (with a #define in lv_conf.h), somewhat like having a "client" side and a "server" side.

Proposal

The client side would only be responsible for setting up and configuring the data structure structures, and the server side for the rendering and input device. Currently, LVGL compiled in WASM occupies ~600 KB, which is significant. I think we can reduce this by getting rid of the rendering part.

[kisvegabor]

Hi,

By rendering you mean e.g. software rendering which actually draws a rectangles, text, etc, or even an upper layer which creates draw_tasks, dispatches them to draw_units.

What would be use case for this separation?

Who will do the rendering in the end?

[AlixANNERAUD]

This can be useful in cases where WASM is used (notably with WAMR on embedded devices) where the client application is sandboxed, preventing direct access to host memory. A naive approach would be to have a buffer per client application (each instance running its own LVGL "rendering engine"), but this is not very memory-efficient.

A better approach would be to compile LVGL as a WASM module without the rendering part (which is likely the heaviest part). The client application would then load this WASM LVGL module, create and set the necessary properties on its objects/widgets, and send references to the parent objects to the host containing the "rendering engine". These references would be attached by the host to one of the screens and then rendered.

Minimizing the size of the WASM part is crucial since the entire code is compiled when building it as a WASM module (similar to a shared library).

[kisvegabor]

I see now but I'm not sure if it will work. Or have you already tried mixing the widget created by multiple LVGL instances?

My concern is that (I assume) each instance will create the widgets in its own memory pool. However it can happen that an other LVGL instance will delete/free the widgets. In this case free need to act on the other instance's memory. If you are using LVGL builtin malloc and free I believe free will crash as it assumes that that memory is allocated in in the current memory pool (and not the other instance's memory pool).

cc @liamHowatt