LVGL Display Rotation: Budget Memory Bandwidth for Portrait and Bar Screens

LVGL display rotation looks like a configuration change but changes the memory path. Rotating an interface from landscape to portrait changes the stride and the access order, and it often adds an additional surface. On a bar-type or portrait panel, the change can be the difference between a smooth scroll and a stuttering one. This guide treats rotation as a display-plus-touch transform, with a memory and latency budget that is set before the first widget is placed.

What does LVGL display rotation change in the memory path?

Rotation changes stride, scan order and buffer count.

A rotated image keeps the pixel count but changes row length and read order, which affects stride, burst efficiency and buffer size.

At 0 degrees, the framebuffer rows follow the display rows. At 90 or 270 degrees, a row of the displayed image corresponds to a column of the stored image, so the stride and the access order change. At 180 degrees, the rows are reversed and the start address moves, but the row length can stay the same.

The memory path sees a different pattern of reads and writes. A rotated access is less sequential, which reduces the benefit of burst transfers and can increase the effective bandwidth. If the design was close to the memory limit in landscape, the same content in portrait may exceed it.

A portrait layout also changes the widget geometry, so the number of redrawn regions and the flush pattern may differ from landscape even at the same resolution. Rotation can also change the buffer count. A hardware path that scans with a rotated stride may avoid a second surface; a software path usually needs a destination buffer. The LVGL rotation documentation covers the API and buffer consequences for the documented release.

When can a controller rotate without an extra surface?

A controller can rotate when its scan direction supports it.

Some controllers can scan in a different order or use a rotated stride, avoiding a second surface; the capability must exist in hardware.

A display controller that supports a rotated layer or a rotated scan can read the existing framebuffer in the required order. The host sets the rotation and the stride, and the controller handles the addressing. No second surface is needed, but the read pattern may still be less efficient than an unrotated scan.

A controller without that capability requires the host to rotate the pixels. The host reads the source, computes the destination address and writes the rotated result. That operation needs a destination surface, and it consumes memory bandwidth on both sides.

A rotated layer may also require the framebuffer base address to be aligned to a larger boundary, which changes the allocation. The distinction belongs in the controller documentation, not in an assumption. A panel or bridge that supports rotation for one pixel format may not support it for another, and a rotated layer may have alignment requirements. Record the supported rotation and the format in the release record.

How does software rotation affect stride and burst efficiency?

Software rotation makes memory access less sequential.

A rotated read or write jumps through memory in a different order, reducing burst efficiency and potentially breaking a bandwidth-limited design.

A software rotation reads a source region and writes a destination region with a different row and column order. The destination writes may be sequential in the rotated coordinate system but scattered in memory, or vice versa. Each jump can break a burst and add bus overhead.

A cache that is enabled can absorb some of the strided writes, but it cannot turn a transposed pattern into a sequential one. The effect is larger for 90 and 270 degrees than for 180 degrees. A 90-degree rotation transposes the access pattern, so a row of the source becomes a column of the destination. If the destination buffer uses a normal stride, the writes are strided and the memory controller cannot merge them into long bursts.

Measure the update rate in both orientations with the same content. A design that is comfortable in landscape may need a smaller buffer, a lower colour depth or a hardware rotation path in portrait. The ST AN4861 LTDC application note documents framebuffer access for specific STM32 families.

Which pixel formats alter the intermediate-buffer cost?

Wider intermediate formats cost more per rotated pixel.

A 32-bit intermediate surface uses twice the memory of a 16-bit one, so the rotation buffer and the bandwidth both grow with format width.

If the rotation is performed in software, the intermediate surface must hold the rotated image. An ARGB8888 surface uses four bytes per pixel, while RGB565 uses two. For the same panel resolution, the 32-bit surface doubles the memory and the write traffic.

A 16-bit intermediate may also change the dithering or colour conversion, so the visual result should be compared, not only the memory. The choice is not only about memory. A 16-bit intermediate may lose alpha or colour precision, which matters if the rotated content is blended later. A 32-bit intermediate preserves the pipeline but costs more. The right choice depends on what happens after rotation.

A format change during rotation should be treated as a separate conversion step. Record the format of the source, the intermediate and the destination. A rotation that changes format at the same time is two operations, and each has its own cost.

How should touch coordinates follow the same transform?

Touch must use the same transform as the display.

If the display rotates but touch does not, taps land in the wrong place; if both transform twice, the error doubles instead of cancelling.

The touch controller reports coordinates in its own native axes. The display driver rotates the image. The touch driver must apply the same rotation, and the application must not apply it again. The transform includes rotation, mirroring, offset and scale, and all of them must match the display path.

A corner test should be repeated after every rotation change, because the transform is easy to leave in the wrong layer. Double transformation is a common bug when the OS, the LVGL port and the application each apply a rotation. The symptom is a touch point that moves in the wrong direction or lands at a mirrored position. Record which layer owns the transform and verify it with a corner test.

The LVGL 9.2 display porting guide documents the display and input interfaces; the exact ownership depends on the port.

What test pattern exposes mirrored or clipped coordinates?

An asymmetric marker reveals mirror and clipping errors.

A distinct corner marker, text and an arrow show rotation, mirroring and clipping that a symmetric pattern would hide.

A symmetric pattern can look correct after a mirror or a 180-degree error. An asymmetric marker in one corner, a line of text and an arrow pointing in a known direction make the orientation unambiguous. If the marker appears in the wrong corner, the rotation is wrong; if the text is mirrored, the transform includes a reflection; if the marker is partly off-screen, the active area is clipped.

A marker that is clipped by one pixel is easy to miss on a small panel, so include a border with a known width. Test the same pattern in every supported orientation. A layout that works in landscape may clip a widget in portrait because the available height and width change. The active area, the safe margin and the widget layout all need to be checked.

Record the pattern, the orientation and the observed result. A screenshot can confirm the rendering, but the panel and touch check must be done on the device.

Which workloads establish acceptable update latency?

Full-screen animation is the worst-case rotation workload.

A full-screen moving pattern exercises the rotated path at the highest traffic; partial updates can look fine while the full-frame case stutters.

A partial update in a small region may fit easily even when rotation is expensive. A full-screen animation forces the rotation path to handle the largest possible area at the frame rate. Scrolling text and a moving gradient are good candidates because they change most of the screen and make a stutter visible.

A partial update that covers a moving element can look smooth while the background is static; the full-frame case is the one that reveals the cost. Measure the frame time and the end-to-end latency in each orientation. If the rotated path is slower, the product may need a lower refresh, a smaller buffer or a hardware rotation path. The decision should be based on the workload the product actually uses, not on a synthetic benchmark.

Record the rotation cost as a percentage of the unrotated frame time, so a later change can be compared. Record the workload, the orientation, the frame rate and the latency. The LVGL display module documentation covers the display object and its buffer behaviour.

What rotation configuration belongs in the release record?

The record names rotation, stride and touch mapping.

The record should state rotation angle, transform matrix, buffer layout, stride, touch mapping and the LVGL version used for validation.

The release record should identify the rotation angle, the transform applied to the display, the transform applied to touch, the buffer layout and the stride. It should state whether the rotation is hardware or software and which surface is used as the intermediate. Add the LVGL version, because the rotation API and buffer behaviour can change between releases.

Include the test patterns, the orientations tested and the measured latency. A record that names only the angle is not enough to rebuild the pipeline; a configuration described only as “rotated” cannot be reproduced or compared.

The table below is a template for the record. It is not a set of limits; the values come from the display, touch and LVGL documentation.

Rotation and touch configuration record

Workload or state	Pixel or buffer format	Measured traffic or energy	Constraint	Evidence source
Landscape baseline	RGB565	Unrotated scan traffic	Refresh rate	Frame timing
Portrait software rotation	RGB565 intermediate	Source read plus destination write	Intermediate buffer size	Memory profile
Portrait hardware rotation	Same storage format	Rotated scan traffic	Controller support	Controller register read
Touch transform	Not applicable	Coordinate mapping only	Single transform owner	Corner test
Bar-type panel	RGB565	Long thin scan pattern	Stride and buffer size	Frame timing

The ST AN4839 cache note is relevant when the rotated buffer is cacheable, because the destination may share a line with other data. The bar-type LCD display category covers the panel format that makes rotation and stride decisions more visible.