Lvgl: Embedded graphics library to create beautiful UIs(github.com)
github.com
Lvgl: Embedded graphics library to create beautiful UIs
https://github.com/lvgl/lvgl
34 comments
There was a thread the other day about Forth on 6051, and someone challenged Forth's utility. I think it fits the same niche: enables quick iteration, exploration, while maintaining a "just right" level of abstraction over the bare metal.
If you want to build something, step 1 is always: empower the developer.
If you want to build something, step 1 is always: empower the developer.
LVGL works with Micropython! Ok disclaimer don’t use the official port it is not good. There is another port https://github.com/lvgl-micropython/lvgl_micropython that has a better setup. I already have it working with custom fonts, and surprisingly Claude can do a reasonable amount of troubleshooting if you get stuck on the API
How does it compare to a generic lib like Dear ImGui? Imgui is tiny and well suited for embedded. Blazing fast
Dear Imgui is immediate mode and primarily designed for rendering with a 3D-capable GPU. LVGL is retained mode and designed for running on microcontrollers where there is no GPU available.
What's a good library like this for building web-only UI?
I'm looking for something higher level than react/vue etc.
I'm looking for something that produces small standalone JavaScript/CSS files that I can embed in a static website.
I'm looking for something higher level than react/vue etc.
I'm looking for something that produces small standalone JavaScript/CSS files that I can embed in a static website.
Looking at the examples, $subj is a classic retained-mode gui, just like Qt, GTK, Wx, Tk, FLTK, MFC, VCL, App/UIKit and so on. Widget tree and methods and event callbacks.
DOM is also that, although a little crappier in some parts. You want to document.createElement(), el.setAttribute(), el.appendChild(), el.addEventHandler(). This obvious interface got buried under the all-consuming react dogma, but it's still there.
jQuery and alikes (zepto, umbrella, cash) can help with wordiness and just stupidly rough DOM signatures, but they don't shift the paradigm.
Edit: If you want a "ready to use" widget hierarchy that simulates desktop paradigms, interrogate llms about modern ExtJS alikes. It was the closest thing, afaik.
DOM is also that, although a little crappier in some parts. You want to document.createElement(), el.setAttribute(), el.appendChild(), el.addEventHandler(). This obvious interface got buried under the all-consuming react dogma, but it's still there.
jQuery and alikes (zepto, umbrella, cash) can help with wordiness and just stupidly rough DOM signatures, but they don't shift the paradigm.
Edit: If you want a "ready to use" widget hierarchy that simulates desktop paradigms, interrogate llms about modern ExtJS alikes. It was the closest thing, afaik.
[deleted]
It's fairly nice just to build a simple embedded UI. There is also a useful editor now, though I haven't used it. It was implemented as a stand-alone program, I would have preferred a VSCode plugin.
It can be a bit difficult to get going on a specific platform, but once you have it going, it's smooth sailing.
It can be a bit difficult to get going on a specific platform, but once you have it going, it's smooth sailing.
PoC from shell scripts with Linux framebuffer, https://github.com/rzr/dialog-lvgl
Any one have experience with this and inkplate EPDs?
If you just want a simple UI editor and don't want to pay for the official tool, give GUI Glider from NXP a try.
https://www.nxp.com/design/design-center/software/developmen...
https://www.nxp.com/design/design-center/software/developmen...
EEZ Studio is another option that's open source, and I find it a bit easier to use too: https://github.com/eez-open/studio
Small typo: GUI Guider
Not well-versed in graphics libraries, but - isn't this reinventing the wheel? I mean, aren't there several others C GUI libraries/toolkits already?
This for MCUs and low powered devices with barely any memory.
32kb of ram and 128kb of flash memory requirement (and some extra space for rendering buffer and framebuffer). Even this is not an insignificant amount for various MCUs.
Which ones do you have in mind?
This is a very low level embedded GUI library when you have a screen where you just set pixel colors or can draw some primitives like lines.
This is not something you would use to program a GUI program running in a real desktop OS.
This is a very low level embedded GUI library when you have a screen where you just set pixel colors or can draw some primitives like lines.
This is not something you would use to program a GUI program running in a real desktop OS.
> This is not something you would use to program a GUI program running in a real desktop OS
But you still could in a framebuffer (actual on linux or emulated). This makes a lvgl GUI a cross platform experience from embedded to web to desktop...you could just make one GUI for your thermostat's physical display which could also be the same GUI you use when accessing it over the network via an emscripten webpage.
But you still could in a framebuffer (actual on linux or emulated). This makes a lvgl GUI a cross platform experience from embedded to web to desktop...you could just make one GUI for your thermostat's physical display which could also be the same GUI you use when accessing it over the network via an emscripten webpage.
The main alternative to LVGL seems to be TouchGFX[1], at least that's the one I've seen mentioned the most in conversations around UI libraries for microcontrollers.
As you wrote these aren't made for desktop apps, but you can use desktop apps to help with UI development using these libraries.
For LVGL there's SquareLine Studio[2], I used it a few years ago and it was helpful. For TouchGFX there's TouchGFXDesigner[3], I haven't used it myself and it seems to run only on Windows.
[1] https://touchgfx.com/
[1] https://squareline.io/
[2] https://www.st.com/en/development-tools/touchgfxdesigner.htm...
As you wrote these aren't made for desktop apps, but you can use desktop apps to help with UI development using these libraries.
For LVGL there's SquareLine Studio[2], I used it a few years ago and it was helpful. For TouchGFX there's TouchGFXDesigner[3], I haven't used it myself and it seems to run only on Windows.
[1] https://touchgfx.com/
[1] https://squareline.io/
[2] https://www.st.com/en/development-tools/touchgfxdesigner.htm...
> This is not something you would use to program a GUI program running in a real desktop OS
Indeed. In addition to that, I think that library is less than ideal for chips with an integrated 3D graphics hardware, like ARM Mali. Except applications with very low-resolution screens way below 1 megapixel, in which case CPU software rendering should be fine.
Indeed. In addition to that, I think that library is less than ideal for chips with an integrated 3D graphics hardware, like ARM Mali. Except applications with very low-resolution screens way below 1 megapixel, in which case CPU software rendering should be fine.
For what it's worth, I've used it on a real "desktop os" albeit on the framebuffer to make a couple full screen (1900x1200 resolution) applications and it worked really well. Biggest issue is lack of native support for multiple mouse buttons, but it was easy to hack that in myself.
You can run it under sdl in a regular windowing desktop environment too, but as stated, that's really not what it's best suited for. It's really meant for the small embedded stuff, for which I personally think it's excellent.
I also thought they were trying to make it capable of talking advantage of some of the accelerated graphics capabilities on some of the small/embedded boards (nxp maybe?), but it's been a while since I was paying attention and I'd have to dig through the GitHub issues/posts again.
You can run it under sdl in a regular windowing desktop environment too, but as stated, that's really not what it's best suited for. It's really meant for the small embedded stuff, for which I personally think it's excellent.
I also thought they were trying to make it capable of talking advantage of some of the accelerated graphics capabilities on some of the small/embedded boards (nxp maybe?), but it's been a while since I was paying attention and I'd have to dig through the GitHub issues/posts again.
> This is a very low level embedded GUI library when you have a screen where you just set pixel colors or can draw some primitives like lines.
There are a few of those like Dear ImGui that are pretty mature and time-tested
There are a few of those like Dear ImGui that are pretty mature and time-tested
For really low powered stuff there's basically this and Adafruit GFX and some monochrome libs
> A fully portable C (C++ compatible) library with no external dependencies.
How does it interact with the screen then?
How does it interact with the screen then?
Ok, so I take from this that it uses pixel buffers directly, and has no opengl support (which would allow GPU acceleration).
You don't really need a GPU when your screen is small and you might only be updating it no faster than ~1 fps and could tolerate ~100ms latency in response to an event. And keep in mind most DOS games were software-rendered on CPUs much less powerful than your modern higher-end microcontroller (e.g. rpi pico, stm32, esp32, etc).
Instead of a full GPU, some microcontrollers may have a special "Blitter" engine...for instance NXP has a "Pixel Pipeline-Processor" (PXP) engine which is just-enough hardware for scaling, rotating, alpha-blending, and copying pixels, and it is for instance possible to configure lvgl to use the PXP to handle such grunt work while leaving the rest of lvgl rendering to software.
Instead of a full GPU, some microcontrollers may have a special "Blitter" engine...for instance NXP has a "Pixel Pipeline-Processor" (PXP) engine which is just-enough hardware for scaling, rotating, alpha-blending, and copying pixels, and it is for instance possible to configure lvgl to use the PXP to handle such grunt work while leaving the rest of lvgl rendering to software.
DOS games on weaker chips still weren't 1fps 100ms. Even without blitters, which commonly appeared only around windows 95 era afair, they ran pretty smoothly for the hardware they had. Any modern cheapest weakest chip will run timespace-warping circles around 8086, not to mention "prev gen" chips.
Exactly my point (I couldn't tell if you were agreeing or disagreeing). I pulled the "1fps 100ms" number as target that a user might tolerate for a typical embedded display. And since as I said modern higher-end microcontrollers are much more powerful that dos-era CPUs (which could run games much faster), the unspoken conclusion I was trying to convince the previous commenter of is that a GPU (beyond maybe a specialized blitter-like pipeline) is unnecessary for the demands of typical embedded application displays. I was also going to give the example that the GUIs of early versions of Windows were software-rendered too.
Out of curiosity I'm looking at the most recent demo video LVGL posted, which benchmarked an ESP32-S2, and it's getting between 50ms-100ms for various tests like rotating multiple bitmaps and such.[1] So seems like the "100ms" number I pulled was quite apprirate for what LVGL can do on on a popular modern microcontroller.
(Also note for any readers: when I typed "1fps", that wasn't a typo for "10 fps". An embedded application would be wanting to do something else for that ~90% remaining CPU time each second that is not spent software-rendering the GUI.)
[1] https://www.youtube.com/watch?v=uHdSQY_k2Mg
Out of curiosity I'm looking at the most recent demo video LVGL posted, which benchmarked an ESP32-S2, and it's getting between 50ms-100ms for various tests like rotating multiple bitmaps and such.[1] So seems like the "100ms" number I pulled was quite apprirate for what LVGL can do on on a popular modern microcontroller.
(Also note for any readers: when I typed "1fps", that wasn't a typo for "10 fps". An embedded application would be wanting to do something else for that ~90% remaining CPU time each second that is not spent software-rendering the GUI.)
[1] https://www.youtube.com/watch?v=uHdSQY_k2Mg
This is for screens usually controlled by microcontrollers, nothing running close to an operating system like Linux and rarely coming with a GPU.
See for examples ILI9341 or SSD1306 displays[1] or integrated boards with (often) an ESP32 microcontroller and a display attached[2].
[1] displays: https://www.google.com/search?q=SSD1306+OR+ILI9341+display&u...
[2] integrated: https://www.aliexpress.us/w/wholesale-ESP32-LVGL.html?spm=a2...
See for examples ILI9341 or SSD1306 displays[1] or integrated boards with (often) an ESP32 microcontroller and a display attached[2].
[1] displays: https://www.google.com/search?q=SSD1306+OR+ILI9341+display&u...
[2] integrated: https://www.aliexpress.us/w/wholesale-ESP32-LVGL.html?spm=a2...
Renderer[1] Draw Units[2] include various GPUs, SDL (and thus OpenGL; looks like SDL2), and a direct OpenGL ES seems in progress[3].
[1] https://docs.lvgl.io/master/details/integration/renderers/in... [2] https://docs.lvgl.io/master/details/main-modules/draw.html#d... [3] https://github.com/lvgl/lvgl/issues/6763#issuecomment-262319...
[1] https://docs.lvgl.io/master/details/integration/renderers/in... [2] https://docs.lvgl.io/master/details/main-modules/draw.html#d... [3] https://github.com/lvgl/lvgl/issues/6763#issuecomment-262319...
This appears to be for low-power embedded devices, not anything that would have a GPU
https://lupyuen.github.io/pinephone-lvgl-zig/
I just recently returned to Zig, and started porting the build file (zig cc calls) to latest Zig (build.zig), but struggling to compile the C LVGL to WASM I suspect because LVGL has a few dependencies on standard C bits n bobs, and I cant find a way to reference the C header files needed.
Anyway, just to say that I found the simplicity of LVGL a breath of fresh air. When I first looked at the PinePhone I was struggling to work out how to access the Mali GPU, thinking I'd be doing UI via OpenGL ES. But seeing how well LVGL and the simple frame-buffer approach works, I abandoned that approach all together. Thanks lupyuen!
It is also nice having the UI in WASM for iterative development without the slow deploy to phone hardware.
I was also able to simply extend an LVGL widget to show a 32bit register contents for debugging my SoC work. A huge time saver.
So a big thanks to the LVGL team on the library, and especially the detailed documentation and examples.