Off-Screen Drawing and Buffers

Earlier work with the Graphics class showed how to draw on a graphical user interface component that is visible on the screen. That raises two natural questions. What if you want to build a drawing somewhere the user cannot see it, inside the computer's memory? And what if the picture you need already exists in a file that you want to load and show? Both questions depend on one fact about how computers handle pictures.

Pause and ask yourself what a computer could possibly store to represent a photograph or a drawing. It cannot keep a picture the way a painter keeps a canvas. Whatever it stores must be something a machine can hold in memory and copy around. Keep that question in mind, because the answer shapes everything that follows.

Notice the careful wording in that definition. The numbers specify color, and each pixel gets its own number. The source material does not say how many numbers a single color needs or what scale they use, so this article does not assume any particular encoding. What matters at this stage is the relationship: one pixel, one color described by numbers, and an image equals the full set of those descriptions.

The easiest way to see the idea is a tiny strip of six pixels. The codes 0, 1, and 2 below stand for three different colors. These codes are invented for this illustration to make the idea visible. They are not a real standard, and nothing in a real system needs to use exactly these values.

Read the strip from left to right. Each box is a pixel, and the number under it is the only thing the computer needs in order to know that pixel's color. Two neighboring pixels with the same number have the same color, so pixels 0 and 1 above are the same color. Changing a pixel's color means changing its number, and nothing else about the image has to be rewritten.

The numbers that show the picture on the screen are stored in a part of memory called the frame buffer. The video card reads the frame buffer many times each second and uses those numbers to color the screen. The frame buffer is therefore the single source of truth for the picture the user sees.

When a program needs to alter what is shown, it does not reach out and repaint the glass directly. It writes new numbers into the frame buffer. The change becomes visible at the next redraw, a fraction of a second later, when the video card reads the updated numbers and colors the pixels again.

In the diagram, only pixel 2 differs after the write. Its number changed from 0 to 1. Pixel 3 keeps its number and therefore its color. The change to the picture is exactly the change to the numbers, and the viewer sees the new color only after the next redraw has read the frame buffer.

A frame buffer is only one place an image can live. Because an image is just a set of numbers, its data does not have to sit in the frame buffer at all. The same numbers can be kept elsewhere in the computer's memory, where a program can prepare a drawing without showing it. This is off-screen drawing: the numbers exist and can be manipulated, but nothing is displayed until they are moved to the frame buffer or otherwise shown.

The numbers can also be stored in a file on the computer's hard disk. Like any other data file, an image file can be downloaded over the Internet. A file is a durable copy: it survives after the program ends and can be sent from one machine to another. When you need the picture again, the file's contents can be loaded back into memory and then displayed.

Java provides standard classes and subroutines for this work. They can copy image data from one part of memory to another, and they can read data from an image file and use it to display the image on the screen. The class names are not part of the source material here, so the diagram below speaks only in general steps.

Read the diagram as a set of routes rather than one fixed sequence. The numbers may come from a file, a download, or ordinary memory, and some may already be in the frame buffer. Whatever route they take, the video card's job at the end is the same: read the frame buffer and color the pixels. Only the frame buffer feeds the screen directly, which is why an image stored elsewhere must eventually be copied into the frame buffer before the user can see it.