Render benchmark · LVGL Coffee Dispenser HMI
On this workload: yes, by about 7% of render time per fully redrawn 800×480 frame — measured as eight back-to-back pairs, because on this machine the absolute numbers drift further than the effect. The memory bill moved the other way: +16% peak RSS, while LVGL's own heap grew only 3%.
Each pair ran back to back on the same pinned core, 9.3.0 first: same clock state, same background load, so the difference inside a pair is the library and not the machine. The absolute level wanders by more than 10% across the session — that is the reason for pairing, and the reason a single before/after run is worthless here.
Rasterization plus the handover of the finished buffer to SDL. Only the first half is LVGL's own work, and only the first half moved.
Measured in-process: lv_mem_monitor() for the pool LVGL manages itself — the number an embedded integrator sizes — and ru_maxrss for the whole process, which also carries the SDL window, the frame buffers and the C library.
| Metric | 9.3.0 | 9.6.0 | Δ | How measured |
|---|---|---|---|---|
| LVGL heap peak | 40 752 B | 42 008 B | +1 256 B (+3.1%) | lv_mem_monitor(), 10 runs, identical every run |
| LVGL heap in use | 10% | 10% | — | of the same 256 KB pool |
| Process peak RSS | 11 707 kB | 13 464 kB | +1 757 kB (+15%) | ru_maxrss, 10 runs |
| Stripped binary | 1.73 MB | 1.97 MB | +0.24 MB (+14%) | release build, same flags |
The split is the interesting part: LVGL's managed pool barely grew, so the extra 1.8 MB is not allocations LVGL tracks. It sits in what the library allocates outside that pool and in the binary itself — more code, more static data, larger draw and cache structures. On a target where the LVGL pool is the constrained resource, 9.6 costs 1.3 KB more; where total RAM is the constraint, it costs about 1.8 MB.
| Pair | 9.3.0 render | 9.6.0 render | Δ |
|---|---|---|---|
| median | 4262 | 3917 | −7.1% |
All values in microseconds. Two further interleaved measurements on the same machine returned −5.1% and −8.0%, and the two ten-run reports −7.3%, so the honest range is 5 to 8%.
For what it costs the integrator, yes. It arrives by bumping a submodule: no configuration change, no visual difference, and on our side only a handful of deprecated calls to migrate. Those ~350 µs per frame are CPU time handed back to the application, and they compound with every redraw.
It is well under the “up to 1.33×” the release notes advertise — expected, not suspicious. That figure is a best case on the boards LVGL measured: ARM cores, usually RGB565, with the blend paths that got the most attention. This run is x86-64, XRGB8888, one draw unit, and a UI of large opaque fills, rounded panels and text. The honest reading: a real single-digit gain on hardware LVGL did not optimise for, paid for with about 1.8 MB more resident memory. If RAM is the binding constraint on your target, that trade needs checking before the upgrade, and the LVGL pool figure above says the growth is not in the part you size yourself.
Partly, and one earlier version of this page did not. It reported 1.23× from a single before/after round; repeating it as pairs put the same comparison at 7%. The first number was machine drift, and it is corrected here rather than quietly dropped.
LV_EVENT_RENDER_START to LV_EVENT_RENDER_READY, so the main-loop delay, the tick handler and the application logic stay outside the number. That is the quantity an embedded integrator budgets.