Graphics Libraries & Fonts on Embedded Systems Development

Graphics Library Landscape

Mon, 01 Jan 0001 00:00:00 +0000

Graphics Library Landscape#

Choosing a graphics library for an embedded display is one of those decisions that shapes an entire project. The library determines the API, what displays can be supported, how much RAM and flash are needed, and whether features like touch input or widgets come built-in. Here is a practical overview of the major options.

LVGL (Light and Versatile Graphics Library)#

LVGL is the most feature-rich option and the closest thing to a “real GUI framework” for MCUs. It provides widgets (buttons, sliders, charts, lists), a layout engine, themes, animations, and even a font converter. The tradeoff is resource usage: LVGL wants at least 64KB of flash and 16KB of RAM as a minimum, and realistically more like 128KB+ flash and 32KB+ RAM for a usable UI. It’s overkill for a simple sensor readout on a 128x64 OLED, but for a thermostat with a touchscreen TFT, LVGL is probably the right tool.

Font Rendering on Embedded Displays

Mon, 01 Jan 0001 00:00:00 +0000

Font Rendering on Embedded Displays#

Text is the most common thing displayed on embedded screens, and the font rendering approach directly affects readability, aesthetics, and memory consumption. There’s a surprising amount of depth here beyond the default 5x7 pixel font that ships with every beginner library.

Bitmap Fonts#

The simplest and most common approach on MCUs: each glyph is stored as a fixed grid of pixels (a bitmap). A 5x7 font uses 7 bytes per character (one byte per row, with 5 bits used). A full 96-character ASCII set in 5x7 takes about 672 bytes of flash — trivial. Larger fonts consume more: a 16x24 font for the same character set is about 4.5KB. Bitmap fonts render fast (just copy pixels), scale poorly (they look terrible at non-native sizes), and have fixed spacing.

Drawing Primitives & Sprites

Mon, 01 Jan 0001 00:00:00 +0000

Drawing Primitives & Sprites#

Every embedded graphics library provides a core set of drawing primitives — the basic shapes and operations combined to build interfaces. Understanding what’s available and how the underlying algorithms work helps produce efficient display code and debug visual issues when things don’t look right.

Basic Primitives#

The standard set found in virtually every library:

Pixel — drawPixel(x, y, color) — the atomic operation everything else builds on
Line — drawLine(x0, y0, x1, y1, color) — usually Bresenham’s algorithm; watch out for endpoint handling at screen boundaries
Rectangle — drawRect() for outline, fillRect() for solid — the fastest fill operation since it maps directly to row/column writes on most display controllers
Circle — drawCircle() and fillCircle() — midpoint circle algorithm; filled circles are noticeably slower than filled rectangles
Triangle — drawTriangle() and fillTriangle() — filled triangles use scanline algorithms and are useful for arrow indicators and custom shapes
Rounded rectangle — drawRoundRect() — quarter-circle corners connected by straight lines

On most display controllers, fillRect() is special because a column/row address window can be set and stream pixel data directly, which is much faster than setting individual pixels. Prefer rectangles for clearing regions and drawing backgrounds.