Choosing a GUI framework for an embedded touchscreen

What decides the pick

Five inputs decide it, in this order:

1. Resolution and frame budget. Pixels x bytes per pixel x frames per second is the bandwidth your renderer has to produce. At 1920 x 1080 in 32-bit color one frame is 8.3 MB; at 480 x 272 it is 0.52 MB. Sixty full frames per second therefore move about 498 MB/s at Full HD and about 31 MB/s at the small panel, a 16-fold difference. A CPU-side renderer feels every bit of that; a GPU-backed stack produces the pixels on the accelerator.
2. Memory floor. LVGL publishes one: a 16, 32 or 64-bit processor above 16 MHz, more than 64 kB of flash for the essentials, and 32 kB of RAM for the library itself. The Linux options bring an operating system, drivers and a userspace; plan those in hundreds of MB.
3. Operating system. Bare metal or a small RTOS leaves LVGL, plus commercial MCU editions of the bigger frameworks. Linux with GPU drivers opens all three main options.
4. Language and team. C++ fits Qt and LVGL directly. Python teams get Kivy or Qt's Python bindings. If the interface already exists as a web app, the browser is a wrapper, not a rewrite.
5. Touch behavior you control. Native stacks hand you raw touch events, so gestures, press feedback and keyboards are yours to define. On a panel without multitouch, on-screen keyboard design for a single-touch panel becomes its own small project, whichever framework you pick.

The three options side by side

Two rows need a note. Neither Qt nor Chromium prints a single RAM number you can plan against, because the total depends on the OS, the drivers and your application. The working figure is the RAM left after the OS boots: hundreds of MB and both fit; a 64 MB board and the decision makes itself, and it is LVGL.

Where Qt with QML wins

Qt with QML is the pick at 1920 x 1080 with animations, transitions and state changes, because the scene graph renders on the GPU and the CPU keeps your application logic. You write machine logic in plain C++ classes and expose them to the QML screens. Build on the Qt 6 line; the Qt 5 series ends at version 5.15.

Expect two costs. QML is its own declarative language with fewer ready-made component libraries than the web, so budget learning time even for a strong C++ team. And the main Qt line needs an operating system: for bare-metal targets the MCU edition is a separate commercial product with its own footprint to fit. Where the same panel would cost a CPU-only renderer about 498 MB/s per full redraw, GPU rendering is the line between usable and sluggish.

Where LVGL wins

LVGL owns the low end. Its documented requirements: a 16, 32 or 64-bit processor clocked above 16 MHz, more than 64 kB of flash for the essential build, and 32 kB of RAM for the library itself; one packaged release lists 16 kB of RAM as a scalable minimum. Reported builds sit well inside small parts. One runs 7 screens of 320 x 240 pixels with about 100 widgets on a board with 264 kB of RAM and 2 MB of flash. An LVGL build for a Wi-Fi microcontroller compiled to 899,323 bytes of flash, 26% of the 3,342,336 bytes available. The license is MIT, so it ships inside closed products.

The trade is tooling and styling: colors, fonts and layouts are set in C, and a third-party visual editor exists if you want drag and drop. Above the 480 x 272 class the bandwidth math from the example starts to bite, and partial updates become the main lever. When a software-rendered panel feels laggy, the causes line up with touch and redraw delays on a slow-rendered panel. If you are weighing a bare drawing library against a full commercial graphics stack on the same class of board, a walkthrough of that graphics-stack choice on a single-board computer works through the trade line by line.

Where a Chromium kiosk window wins

Run the interface in a browser when the UI is already a web page: a dashboard, a scheduling view, anything your web team maintains. You inherit the web's component ecosystem, and the compositor keeps 1080p smooth on the GPU. The cost is footprint: a layout engine, a JavaScript engine and a compositor make it the heaviest option here, so it belongs on boards with hundreds of MB of RAM under a light OS.

Kiosk behavior needs locking down like any public screen. Full-screen startup with no browser chrome is covered by autostarting a Chromium kiosk window on a Linux panel; pages sized for one fixed resolution need the scaling checks for a kiosk browser that sizes pages wrong; and confirm before you commit that your shell can disable pinch zoom, because some web wrappers keep that control to themselves. If the kiosk has to play video, settle how the browser decodes it early: video decode configuration on embedded Linux varies by board and build, and your board's vendor documentation is the place to start.

Example: the numbers on two boards

Scenario: board A is a Linux single-board computer with a GPU and 1 GB of RAM, driving a 1920 x 1080 touch panel at 32-bit color. Board B is a bare-metal microcontroller with 264 kB of RAM and 2 MB of flash, driving a 480 x 272 panel. Both interfaces target 60 frames per second.

Board A, frame size: 1920 x 1080 pixels x 4 bytes = 8,294,400 bytes, about 8.3 MB per frame. A full redraw at 60 fps moves 8,294,400 x 60 = 497,664,000 bytes/s, about 498 MB/s. Qt with QML and Chromium both hand that work to the GPU, so 1080p stays smooth on board A, and with 1 GB of RAM there is headroom for either stack. The decision rests on the interface, not the hardware: a C++ UI becomes Qt with QML; a web UI becomes a kiosk window.

Board B, frame size at 32-bit color: 480 x 272 x 4 bytes = 522,240 bytes, about 0.52 MB, which cannot fit in 264 kB of RAM. At 16-bit color the frame is 480 x 272 x 2 = 261,120 bytes, about 0.26 MB, which alone eats most of the budget. So the panel controller holds the frame in its own graphics RAM and the microcontroller flushes changed regions only: a 160 x 48 button region is 160 x 48 x 2 = 15,360 bytes, about 0.02 MB per press. LVGL's floor of 32 kB of RAM and 64 kB of flash leaves room for that buffer plus the application code. The browser has nothing to sit on, because board B runs no OS. Decision: board A gets Qt with QML for a C++ interface, board B gets LVGL.

The rest of the shortlist

• Kivy puts a touch-first toolkit in Python. Sensible for quick internal tools; check how it behaves on your target hardware before you build a product on it.
• Qt's Python bindings keep a Python team inside the same framework the C++ developers use, which pays off the day both teams touch the same screens.
• Slint offers declarative markup with Rust and C++ bindings and runs close to the metal, which puts it in the same slot as LVGL with different tooling.
• SDL gives you pixels and events, not widgets. Every button, list and keyboard is yours to write.
• Embedded Wizard and other commercial MCU frameworks occupy the same bare-metal slot as LVGL with their own design tools; read the free tier's limits before you prototype on one.
• Android as the board OS brings its own UI toolkit and the size of a full Android build. Sensible when the panel runs more apps than yours.

The decision

• 1920 x 1080 panel, Linux with GPU drivers, C++ codebase: Qt with QML.
• No operating system, a small RTOS, or a panel in the 480 x 272 class with a kilobyte-scale memory budget: LVGL.
• The UI already exists as a web page, and the board carries hundreds of MB of RAM: a Chromium kiosk window.
• Python team: Kivy for a one-off internal tool; Qt's Python bindings for anything you will maintain.

Whichever stack you land on, test it on the hardware: startup time and runtime behavior on the panel itself belong in the decision before the board layout is final.

Recommendation: for the case this page opened with, a 1920 x 1080 touch interface in C++ on a Linux single-board computer, build it in Qt with QML: keep machine logic in plain C++ classes and let QML own the screens. Switch to LVGL when the board has no operating system, or when the panel drops to the 480 x 272 class and the board is a 2 MB-flash microcontroller. Choose the Chromium kiosk window only when the interface is genuinely a web app, and lock its zoom, gestures and startup behavior before you ship.

When the screen does not run your code

One more case: the panel's job is to show notices, videos or a status page that no application drives. Then the framework question disappears. An offline signage player handles offline playback of images and video, or runs your own Android app, on screens built for the shop floor. We make shop-floor screens and andon boards for exactly that job. Keep the decision above for anything that must read and write machine data: a signage player is a content screen, and it does not stand in for an HMI.

Questions