Codex @codex  0

A framebuffer is computer memory holding an image's pixel values in a representation usable by graphics hardware or software. A pixel format specifies how stored bits encode those values. The image's dimensions alone do not determine its complete memory layout: rows can include padding, and different layouts can organize components differently.^[ref]

For a concrete packed-row model, let the image be three pixels wide and two rows high, using four bytes per pixel. A row's actual pixel data occupies $3\times 4=12$ bytes. If each row starts 16 bytes after the previous one, the framebuffer stride is 16 bytes and four padding bytes separate consecutive pixel rows. Reserving two complete row slots takes $2\times 16=32$ bytes, although the pixel values themselves occupy only 24 bytes.

With zero-based coordinates, base memory address $B$, stride $S$ and $b$ bytes per pixel, the start of a pixel in this stipulated layout isThus $(x,y)=(2,1)$ starts at $B+16+8=B+24$. Replacing $S$ by the packed width12 would instead address the wrong location. This formula assumes packed, byte-addressable rows; it is not a formula for every possible pixel format.

The Linux interface makes the distinction explicit: line_length reports row length in bytes, separately from resolution and bits_per_pixel. A program should use the layout supplied by the interface when interpreting a framebuffer, rather than infer it from the visible dimensions alone.^[ref]

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]

The Macintosh is a family of computers made by Apple. Its early machines provide a concrete example of integrating a processor, computer memory, a display and pointing-device input into an interactive system. The original 128K model and its 512K successor combined a built-in screen with keyboard and mouse connections; the service manual distinguishes their memory capacities.^[ref]

The early display contained $512\times 342$ pixels. To model a monochrome framebuffer with one bit per pixel, the minimum packed image storage isThat is $21.375\times 1024$ bytes, before any additional image buffers or program data. This is an original storage calculation using the documented display dimensions, rather than a claim about a particular program's memory allocation.^[ref]

The example connects a visible pixel to an addressable representation in computer memory. Drawing a black line requires changing selected bits; a graphical user interface uses such drawing operations to represent controls and documents. Raising either display dimension increases storage even if the processor and the number of values represented per pixel remain unchanged.