 Framebuffer stride

A 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.^[ref]

Assume each pixel occupies $b$ complete bytes, rows advance by a positive stride $S$, and coordinates are zero-based. With base address $B$,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 usesThere 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: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^{\prime }=B+19$. Its next row still begins at $B^{\prime }+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.^[ref]