Double Buffer
A display does not show you a picture. It sweeps, one scanline at a time, reading whatever is in the buffer at the moment it arrives. If something rewrites that buffer while the sweep is halfway down, the frame the display emits is the top of one picture and the bottom of another, with a seam between them. Richard Shoup's SuperPaint at Xerox PARC displayed its first picture in early April 1973, and a second buffer is not a thing you can have until you have one, and SuperPaint is the machine that proves the point: its second frame buffer was designed, costed and never built.
New to drawing on a screen? Start here
A grid of dots on a clock
A screen is a grid of coloured dots, redrawn from top to bottom on a fixed beat. Everything drawn on it is a decision about which dots and what colour, made before the beat arrives.
The clock is the part that makes this hard. It does not wait, and it does not care whether the drawing was finished, so a picture that took too long is shown half-done. Most of the machines in this topic exist because of that deadline rather than because of the picture.
The machine for this idea on its own is Eight Sprites, if you would rather press it than read about it.
The frame you are looking at is not the one being drawn
1 One buffer, and a beam that is already halfway down it
A display does not show a picture. It sweeps, one scanline at a time, reading whatever is in the buffer when it arrives. Drag the beam to see which line it is on.
2 A write that lands mid-sweep, and the frame the display emits
Now write a new picture into the buffer while the beam is partway down. The lines it had already passed still carry the old picture; the rest carry the new one. The frame the display emits is both, with a seam where the beam was.
3 A second buffer, and the seam that stops appearing
Give the writer its own buffer and swap them only between frames. Every scanline of an emitted frame now comes from one picture, at the same write time that tore the frame above.
4 What it cost: up to one refresh of latency, measured
The seam is gone and something was paid for it. The picture on screen finished being drawn before the last swap, so it is older than the one the writer has already finished. At sixty hertz a refresh is about sixteen and two thirds milliseconds, and the wait is the part of one that was left when the write landed.
| buffers | pictures in a frame | seam | wait before it is seen |
|---|
These ran in this browser when the page loaded. Each claim, whether it held, and the number behind it.
| claim | held | measured |
|---|---|---|
| A 640 by 480 frame 8 bits deep is 307,200 bytes, which is the figure in the paper | yes | 640 x 480 x 1 = 307,200 |
| The seam's scanline is the same whether it is divided for or counted to | yes | agreed at all 1,000 write times tested |
| A write halfway down a single-buffered frame emits two pictures at once | yes | the emitted frame carries frame 1 above frame 2, seam at scanline 12 of 24 |
| With a second buffer every scanline of a frame comes from one picture | yes | one picture across all 24 scanlines |
| A write that lands before the sweep starts is not a tear | yes | seam at scanline 0 |
| and a frame nobody wrote during is not a tear either | yes | no write, no seam |
| The second buffer costs a wait for the swap, and the earlier the write the longer it waits | yes | a write a quarter of the way down waits 75% of a refresh; three quarters down waits 25%; with one buffer it waits none of it and tears instead |
What is real here, and what is not
This page cannot tear, so it models tearing
A browser composites, which is why a page on the internet does not normally show you a torn frame — the compositor is double buffering on your behalf, and it is one of the reasons tearing is unfamiliar now. Nothing here is your display failing. What is drawn is a model of the scanout: a beam sweeping down the raster at a stated rate, a writer changing the buffer at a stated moment, and the frame those two produce together. The seam's position is computed from those two numbers rather than drawn where it looks good, and the page prints the scanline it lands on. At 100% the sweep has finished: the emitted frame is entirely old, and the new picture belongs to the next sweep. An earlier version clamped that boundary onto the final scanline and incorrectly reported a tear.
The frame buffer's numbers are the paper's, and the arithmetic is checked
Shoup writes that a video image minimally contained 640 pixels horizontally, 480 vertically and 8 bits in depth, for a total of 307,200 bytes. The page checks that multiplication rather than repeating the total, because a number quoted from a source and a number derived from its own inputs are different claims and only one of them can be wrong quietly.
The date is the frame buffer, and SuperPaint's second one was never built
SuperPaint displayed its first picture in early April 1973, which Shoup says in the first person in the IEEE Annals account, and the chronology takes that rather than a secondary summary of it. What the chronology does NOT claim, and what an outside audit was right to press on, is that SuperPaint double-buffered. It did not. The same paper says so, in a passage this page deliberately does not quote: the scan is two columns and its text layer interleaves them, so no contiguous run of words reproduces the sentence. Described rather than quoted, then: Shoup writes that an additional cage of memory cards was originally to have provided a second 8-bit frame buffer in the centre of the rack, that it was deemed too expensive, and that it was never added. That fact was in this page's own archived copy of the paper from the day it was cited, and nothing here had read it against the page. So 1973 dates the arrival of a full-frame store you could afford one of, which is exactly what makes the second one a decision rather than a detail. The two-buffer technique modelled above is dated to nothing here. Finding the earliest documented machine that actually swapped between two frame stores is open work, and the date will move if one is found.
What is not modelled
No vertical blanking interval of any real duration, no vsync in hardware, no triple buffering, no GPU, no compositor. The refresh rate and the write time are yours to set and are not measured from your display. A real tear also depends on where the two frames differ, and this shows the worst case, where they differ everywhere.
The latency is the honest half of the story
Double buffering does not make anything faster. It costs latency: the picture you are shown finished being drawn before the last flip, so at sixty hertz it is up to sixteen and a bit milliseconds old and usually less, and the page measures that rather than mentioning it. A page that showed only the seam disappearing would be an advertisement.
No sound
A tear is a spatial artifact. There is nothing to hear.
Sources
- Richard Shoup, SuperPaint: An Early Frame Buffer Graphics System, IEEE Annals of the History of Computing 23(2), 2001, pages 32 to 37. Read for this page: the first picture in early April 1973, in the first person, and the frame buffer's dimensions and byte count.
- The same paper in the ACM's record, for the citation and the DOI.
- Logical Art, the studio this belongs to.