A common assumption in embedded UI is that you pay more, or accept tighter hardware lock-in, in exchange for better performance. A recent third-party benchmark by Silicon Signals put that assumption to the test: they built the same UI, ran it on the same hardware, and measured LVGL, TouchGFX, and Qt for MCUs side by side.
The headline result is the interesting part. On performance and memory, the three frameworks land in roughly the same place. And once raw performance stops being a differentiator, the obvious question becomes: what are you actually paying for when you pick a commercial or vendor-locked framework?
How the benchmark was set up#
To keep the comparison fair, every framework rendered an identical set of six demo screens on the same board, under the same RTOS.
The six demos were chosen to stress different parts of the rendering pipeline:
- Static: shapes, gradients, alpha blending (baseline / idle load)
- 2D: rotating and translating images
- SVG: animated vector graphics
- Video: full-screen "Big Buck Bunny" playback (TouchGFX decodes MJPEG at runtime; LVGL and Qt replay pre-decoded JPEG frames)
- Text Scroll: continuous scrolling text
- Cluster: a full automotive instrument cluster
LVGL was tested at version 9.4.0 with the new LVGL Editor, on FreeRTOS 10.4.6, the same OS used for all three frameworks.
Performance: basically the same#
Here are the per-demo CPU load and render-time figures. The numbers trade blows: each framework wins some demos and loses others, but all three stay comfortably in real-time territory. Most render times land under 12 ms. Scrolling text is the one outlier, where LVGL and TouchGFX both sit in the 20–28 ms range.
| Demo | LVGL | TouchGFX | Qt for MCUs |
|---|---|---|---|
| Static | 2% / 1–3 ms | 6–8% / 0–1 ms | <1% / 3 ms |
| 2D | 30–33% / 3–4 ms | 7% / 3 ms | 5–6% / 8–9 ms |
| SVG | 15–16% / 9–12 ms | 23–26% / 7–9 ms | 14–15%* / 6 ms* |
| Video | 5–6% / 5–6 ms | 4% / 4 ms | <1% / 5 ms |
| Text Scroll | 4–5% / 23–28 ms | 59–62% / 20–22 ms | 2% / 9–10 ms |
| Cluster | 12% / 8 ms | 10% / 1–2 ms | 2–3% / 8–9 ms |
Each cell is CPU load % / render time in ms. There is no consistent winner: TouchGFX is the lightest on video and renders the cluster fastest, but spikes to 59–62% CPU on scrolling text and 23–26% on SVG. LVGL is light on video too, and heavier on the 2D demo. TouchGFX also decodes the video at runtime. LVGL and Qt replay pre-decoded frames, so that row is not like-for-like. Qt for MCUs posts the lowest CPU figures in most demos, but part of that comes from moving work to compile time rather than from a faster runtime: its SVG assets are pre-rendered bitmaps, and its text demo uses a static text item. The practical takeaway is that all three render the same UI smoothly on this hardware.
Qt for MCUs does not render SVG at runtime. Its SVG assets are pre-rendered to bitmaps at compile time and baked into the binary, which is why its SVG figures are marked with *. LVGL and TouchGFX both render SVG at runtime, with LVGL going through its SVG engine with NeoChrom GPU acceleration.
Memory: basically the same, with one LVGL edge#
Memory usage tells the same story. The three frameworks sit within a tight band on RAM and internal flash. The one place they diverge is external flash, where LVGL uses the least by a wide margin.
| Metric | LVGL | TouchGFX | Qt for MCUs |
|---|---|---|---|
| Total RAM | 2164 KB | 1975 KB | 1719 KB |
| Internal flash | 559 KB | 426 KB | 519 KB |
| External flash | 24 MB | 44 MB | 80 MB |
LVGL's external-flash footprint came in at 24 MB versus 44 MB for TouchGFX and 80 MB for Qt, largely thanks to GPU-accelerated TSC6 texture compression on the NeoChrom GPU. On a BOM where external flash is a real cost, that gap is not noise.
So what are you actually paying for?#
If the three frameworks render the same UI at the same quality, with comparable CPU and memory, then performance is no longer the thing that separates them. What's left is licensing and portability, and this is where the picture changes sharply.
| LVGL | TouchGFX | Qt for MCUs | |
|---|---|---|---|
| License | ✅ MIT (open source) | ST SLA0048 | Commercial |
| Cost | ✅ Free | Free | Paid |
| Royalties | ✅ None | None | Depends on license |
| Hardware | ✅ Any MCU / MPU, any vendor | STM32 only | Selected platforms |
| Portability | ✅ High | Low (STM32-locked) | Moderate |
Two conclusions fall out of this directly:
Why pay for Qt for MCUs? If a paid license bought you meaningfully better performance, the math might work. But the benchmark shows it doesn't. Qt delivers comparable results to a framework that is free and MIT-licensed, and some of its lowest CPU figures come from pre-rendering work at compile time rather than from a faster runtime. You'd be paying for tooling and support, not for a faster UI. And you'd accept the largest external-flash footprint of the three plus no runtime SVG.
Why accept TouchGFX's vendor lock-in? TouchGFX is free, but only on STM32. The moment your product roadmap touches NXP, Espressif, Renesas, an MPU, or Embedded Linux, you're rewriting the UI. LVGL runs the same codebase across all of those vendors and platforms, from a bare-metal Cortex-M to a Linux MPU, with only the display and input drivers to swap.
When performance is basically the same, the framework that's free, open source, and runs on any silicon is the one that keeps your options open.
LVGL gives you that performance parity with no license fee, no royalties, no vendor lock-in, and a 600+ contributor community behind it, all under the permissive MIT license.
Reproduce it yourself#
The best part of this benchmark is that you don't have to take anyone's word for it. Silicon Signals open-sourced all three demo projects, so you can flash them to an STM32U5G9J-DK2 and measure for yourself.
This repository contains benchmark test projects developed for the STM32U5G9J-DK2 board using LVGL.
The TouchGFX and Qt for MCUs demo projects are available in the same organization:
This repository contains benchmark test projects developed for the STM32U5G9J-DK2 board using TouchGFX.
This repository contains benchmark test projects developed for the STM32U5G9J-DK2 board using Qt for MCU.
Takeaway#
Performance is the first thing teams compare when choosing an embedded GUI framework, and on this hardware it's effectively a tie. That's good news, because it lets the decision rest on the things that actually have long-term consequences: licensing cost and hardware freedom.
On both of those, LVGL is the straightforward choice. Same performance, zero cost, any silicon. If you want to get started, the documentation and a PC simulator will get you to a running UI in an afternoon, on whatever hardware you choose.
Benchmark conducted by Silicon Signals, a product engineering firm. Read the full write-up and whitepaper.