The Framebuffer

A block of memory that became a picture

Before the framebuffer, a computer screen was a window onto a program's logic, not a canvas. The display showed what the processor chose to draw — a moving dot on a radar trace, a line in a vector CRT beam — and it forgot the image the moment the beam moved on. Nothing persisted. The idea that you could paint, erase and paint again depended on a different arrangement entirely: a region of memory dedicated to holding the state of every pixel on the screen, continuously read out to drive the display hardware. That arrangement is the framebuffer, and almost everything in digital image-making follows from it.

The principle is straightforward. Take a rectangular grid of pixels — say, 640 across and 480 down. Allocate memory so that each pixel has a fixed address: position (x, y) maps to a byte or a word at a known offset in the buffer. The display hardware reads that memory from top-left to bottom-right, row by row, at the refresh rate of the monitor, converting each stored value to a voltage that drives the electron gun or, later, the liquid-crystal cell. Change a value in memory, and the next refresh cycle shows the change on screen. The latency is at most one frame period — typically a sixtieth or fiftieth of a second. The result is a display that reflects memory rather than commanding it, which means software can write pixel values in any order, at any time, and the screen will show whatever the buffer holds.

The depth of the buffer — how many bits per pixel — determines what the stored value can encode. A one-bit buffer gives two states: on or off. Early systems used exactly this for text and simple graphics. Four bits give sixteen values; eight bits give 256. But 256 values for what? In a palette-mapped system, each eight-bit value is an index into a separate colour lookup table (CLUT), a small array of actual RGB triplets. The hardware reads the index, fetches the corresponding red, green and blue values from the CLUT, and sends those to the display. This made colour framebuffers economical: the CLUT held the actual colour data, while the buffer itself could stay narrow. Richard Shoup's SuperPaint system at Xerox PARC, built around 1973, used exactly this architecture — an eight-bit-per-pixel framebuffer with a programmable colour lookup table — and it was the first system that let a person paint interactively into persistent pixel memory and see the result immediately.

As memory costs fell through the late 1970s and 1980s, "true colour" or "direct colour" framebuffers became viable: 24 bits per pixel, eight for each of red, green and blue, giving 16,777,216 possible colours per pixel without any lookup table. Later still, 30-bit and 48-bit "deep colour" framebuffers emerged, storing ten or sixteen bits per channel to reduce banding in gradients and to give compositing pipelines headroom above the final display's gamut. A framebuffer used in visual effects work today may store 16-bit floating-point values per channel — half-float, in the IEEE 754 sense — so that a single pixel can represent a light value many times brighter than white, which matters when you are compositing a sunlit sky against a dark interior and have not yet decided where to put the exposure.

Memory, address, and the geometry of the grid

The address arithmetic inside a framebuffer is simple but consequential. The offset of pixel (x, y) from the start of the buffer is y × stride + x × bytes_per_pixel, where stride is the number of bytes in one complete row. Stride is not always equal to width × bytes_per_pixel: hardware and operating-system allocators often pad each row to a power-of-two boundary for memory-access efficiency. The gap between the end of one row's pixel data and the start of the next is called padding; the full row length including it is the pitch, or row stride, and failing to account for it produces the diagonal-tear corruption that anyone who has written low-level graphics code has encountered.

The buffer is linear in memory; the grid is rectangular on screen. That mapping is the raster — the word comes from the Latin for a rake, via the German Raster (a grid or screen), applied to the left-to-right, top-to-bottom scan pattern of a cathode-ray tube. Each horizontal pass of the CRT beam is a scan line, and the complete set of scan lines for one frame is a raster. A framebuffer is a raster in memory: a pixel's address encodes its position in that scan-line structure. The correspondence between memory address and spatial position is so direct that "raster graphics" and "framebuffer graphics" are effectively the same thing, distinguished only by which aspect you are emphasising — the display geometry or the memory organisation.

Before the framebuffer, a computer screen was a window onto a program's logic, not a canvas.

What the framebuffer made possible, architecturally, was decoupling the processor from the display. Before it, drawing a continuous image required the CPU to regenerate the display contents many times per second — a refresh burden that left almost no cycles for computation. With a framebuffer, the refresh hardware reads memory autonomously; the CPU writes to the buffer whenever it has something to change. This separation is the basis of every graphics accelerator ever built: a dedicated GPU writes into a framebuffer that the display controller reads out, and the CPU is free to do other work. The Xerox Alto, developed at Xerox PARC in the early 1970s, used a bitmap framebuffer mapped to a portrait-orientation display, driving the pixel-mapped screen that inspired every windowed interface that followed.

Double buffering and the problem of tearing

One framebuffer is enough to display a static image. Animation introduces a complication: if the display hardware is reading from the same memory that the program is writing into, a partially-updated frame will be visible on screen — a condition called tearing, where the top of the frame shows the new image and the bottom shows the old one, divided by the scan line that happened to pass during the write. The standard solution is double buffering: allocate two framebuffers of equal size, draw the next frame into the back buffer while the display reads from the front buffer, then swap the pointers at the moment of vertical blanking — the brief interval when the CRT beam returns from bottom-right to top-left, or when the LCD's display controller resets. During the blanking interval, nothing is being displayed, so swapping is safe. The display then reads what was the back buffer, now promoted to front, and the program begins writing into the other.

The swap itself is almost free: on modern hardware, it is a register write that changes which address the display controller scans from. What costs time is filling the back buffer, which is why frame rate and resolution are in direct tension. A 4K framebuffer at 32 bits per pixel holds 33 megabytes per frame; at 60 frames per second, the GPU must produce two gigabytes of new pixel data per second before any other work is counted. That number drives GPU memory bandwidth specifications more directly than almost anything else.

The framebuffer is, in the end, a very old idea dressed in continuously updated hardware: a surface that holds a picture, waiting to be changed. What makes it the foundation of digital image-making is not sophistication but completeness. Every pixel has an address; every address can be written; the display shows what is there. From that, everything else — painting, compositing, antialiasing, animation — is a matter of deciding what to write and when.