= Framebuffer stride
{title2=$S$}
A \b[framebuffer stride] is the <memory address> increment between the starts of consecutive image rows in a specified <framebuffer> layout. For a row-based <packed pixel format>, it is commonly measured in <bytes>. It includes any padding between rows, so the image width and <pixel format> alone do not determine it. The Linux frame-buffer interface reports this byte count as `fb_fix_screeninfo.line_length`.<The Frame Buffer Device API in the Linux Kernel documentation>[Section2, FB_TYPE_PACKED_PIXELS and end-of-line padding; section3, line_length]{ref}
Assume each pixel occupies $b$ complete <bytes>, rows advance by a positive stride $S$, and coordinates are zero-based. With base address $B$,
$$
\operatorname{address}(x,y)=B+yS+xb.
$$
This formula describes the stated packed-row layout. Formats with a different organization need their own addressing rule.
For an original example, choose an image width $W=5$, height $H=3$ and $b=3\,\mathrm{bytes}$ per pixel. The pixel data in each row occupies 15 bytes. If the chosen allocator aligns each row to a multiple of eight bytes, it uses
$$
S=8\left\lceil\frac{Wb}{8}\right\rceil=16\,\mathrm{bytes}.
$$
There is one padding byte per row slot. The last pixel, at $(4,2)$, starts at $B+2(16)+4(3)=B+44$ and occupies offsets 44, 45 and 46. Three complete row slots occupy 48 bytes, whereas the span through the last pixel ends at exclusive offset47:
$$
(H-1)S+Wb=47\,\mathrm{bytes}.
$$
The allocation rule and the bytes actually containing pixels are distinct parts of the layout.
A cropped view need not become tightly packed. Starting a three-pixel-wide crop at original coordinate $(1,1)$ gives new base $B'=B+19$. Its next row still begins at $B'+16=B+35$, although each cropped row contains only nine pixel bytes. Substituting nine for the stride would instead start that row at $B+28$.
Query the actual layout supplied by the interface before traversing memory. In the documented Linux interface, a successful format change can also update `line_length`, so the stride belongs to the selected layout rather than being an immutable consequence of visible width.<The Frame Buffer Device API in the Linux Kernel documentation>[Section4, format configuration and updated type, visual and line_length fields]{ref}
Back to article page
