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.
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: a whole frame 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 a half 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 precisely why no page on the internet shows you a torn frame. 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.
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 author's own sentence
SuperPaint displayed its first picture in early April 1973, which Shoup says in the first person in the IEEE Annals account. The chronology takes that rather than a secondary summary of it.
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 a frame: 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 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.