[VOTE] Could you use LVGL if it were based on C++?


We are considering to move the internals of LVGL to C++ but keep the API, speed, and size similar to the current.

It’d be awesome to know if you rely on a compiler (or environment in general) that doesn’t support C++.

Please, help our decision by sharing your case. Thank you! :slight_smile:

To better understand the requirements, if you can use only C, please write a comment and describe your situation.

  • I can use only C
  • I’m ok with C++ too

0 voters

To make things clear, we are not planning to rely on any C++ features that are known for excessive code size or bloat. Performance should be similar or identical to the current version - this is mainly a syntactical change that would get rid of some ugly hacks in the current codebase.

I’m mainly using lvgl on ESP32, Teensy 3.6+, and FPGA targets.

I’ve updated the first post.

Why not other languages like Go or Rust?

Probably because you will not able to run it on 8-bit … 32-bit tiny MCU’s.

1 Like

There are compilers for 32 bit mcus in both languages. And I dont think LVGL was made for 8 bit MCUs

We want a language that is fully compatible with C/C++ infrastructure without requiring extra bindings.


I agree with you

Anyone, who can use C only, could you explain your situation? At first glance, C++ should be available everywhere (for any MCU, able to run LVGL). I’d like to understand your cases.

C++ should be available everywhere

Java is available everywhere, too.

1 Like

No, i cant use java on 8 bit mcu

I can use lvgl C only. I am working on dualboot solution for android devices, https://github.com/Android-Boot-Manager and in some cases we replace phones bootloader. For example on Volla Phone we have 1 mb partition for lk (little kernel) based bootloader. We have a lot of problems fitting evrything there, and there is no space for libc++. But libc is there, bcz lk needs that.


@luka177 are you sure libc++ will be mandatory? with --specs==nano-specs my projects are built with ordinary newlib-nano.

Here are no wish to write in cpp style, only in “c with classes”.

No, i cant use java on 8 bit mcu

Oh, sure you can, just google e.g. AVR JVM. And you could, some 20 years ago, too; e.g. using the TINI stack in Dallas Semiconductor DS80C380.

But that’s not the point.

The point is, that a tool being available does not mean it’s suitable. There are many, MANY reasons to use or not to use a given tool/feature.

C is the least common denominator for microcontrollers in particular, and LVGL being in C is a precious asset, increasingly rare these days.

OTOH, I understand Gabor’s desire to migrate to C++ - at the end of the day, he painstakingly reproduced some of the features which would come automatically with C++.

For me personally, C++ as a showstopper, though.


1 Like

Still what about size, wount lvgl become bigger?

1 Like

It’s likely to not change that much in either direction, since the existing “fake” objects would be replaced by standard C++ logic. However, I haven’t done any profiling of C++ classes to know the exact cost compared to our current solution.

In general - no, size will be ~ the same.

Having a proper C++ API will make using LVGL. For example, I wouldn’t need to remember if method X comes from obj or from Label. Just typing my_label.set_pos in the IDE and the autocompletion will find it.

BTW, the limits that I face are around RAM and screen update speed (number of pixels to push to the TFT controller) and not that much around ROM, code size, or computation speed.

1 Like