Drawing Lines and Shapes Pixel by Pixel

Suppose you want a program to place a dot on a window. The program has to say exactly where the dot goes, and it needs a way to name that spot without ambiguity. A phrase such as near the top and a bit to the right is not precise enough for a machine. What the program needs is a numbering scheme: a set of rules that turns every location on the surface into a pair of numbers. That scheme is the coordinate system.

Before we can use a coordinate system, we need to know what the surface is made of. The numbers only make sense against that underlying structure, so the next part of this article looks at the screen itself before it looks at the numbers.

Look closely at any screen and you will eventually see that the image is assembled from small squares. These squares are called pixels, and the whole display is a grid of them. Every pixel can be given its own color, and each one can be given a different color from its neighbors.

Drawing on the screen has a very concrete meaning: it is the act of choosing the color of particular pixels. A straight line is not a special object stored by the screen. It is a chain of pixels that have been colored so that they look like a line to the eye. A diagonal line, a circle, or a filled rectangle follows the same rule: the underlying operation is always to decide which pixels to color and with what color.

The grid below shows a small rectangle of positions, four across and three down. Read it as a set of moves from the origin. Each step to the right increases x by one, and each step downward increases y by one. The highlighted position (2,1) is reached by taking two steps right and one step down from the corner. Every integer pair names exactly one spot in the rectangle, and every spot in the rectangle has exactly one integer pair.

In this system the origin sits at the upper left, not the lower left. Moving down the screen makes y larger, and moving right makes x larger. This is the reverse of the vertical direction used in ordinary school graphs, where the origin is usually drawn at the lower left and y grows upward. Once you internalize the screen direction, you will read every coordinate on a screen correctly.

Coordinates by themselves only name spots. Something has to turn those names into colored pixels, and in this model that role belongs to the graphics context. A graphics context is the thing that draws, and it draws inside a rectangle made up of pixels. Anything you ask it to draw is restricted to that rectangle.

Every position you give the graphics context is interpreted relative to the rectangle's upper left corner, not relative to the whole screen. So the graphics context ties together three ideas: a drawing surface, a grid of pixels on that surface, and a coordinate system that tells it where to act. When it draws into that rectangle, the pixels that change are the ones that appear on the screen.

There is a subtle point worth slowing down for. When we say the position (0,0) is the upper left corner, it is tempting to picture that coordinate as belonging to the first square. The more precise statement is that the coordinates belong to the grid lines that separate the pixels, not to the pixels themselves. Picture the boundaries between squares as a set of lines running across and down the surface. Each integer coordinate names one of those line intersections, and the pixels are the regions between them.

Put the pieces together and trace what happens when a program draws a line. The program does not hand the screen a line object. It works through a sequence of positions, one at a time, and for each position it decides whether that pixel should take the drawing color. Each chosen pixel is named by its (x, y) pair relative to the graphics context's rectangle, so the program can compute the name of every pixel it touches.