Pixel Grid and Screen Representation

Suppose you want a program to place a dot on a window. The program has to say exactly where the dot goes. 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 it, we need to know what the surface is made of, because the numbers only make sense against that underlying structure.

Look closely at any screen and you will 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.

This gives drawing a very concrete meaning. 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. The same is true of a circle, a letter, or a photograph: each is a particular choice of pixel colors across the grid.

A position inside a rectangle of pixels is written as a pair of integers, traditionally called x and y, and written together as (x, y). The count begins at the upper left corner, which is assigned the pair (0,0). From that origin, x measures how far a position lies from the left side and grows as you move right. The value of y measures how far a position lies from the top and grows as you move downward.

The origin is placed at the upper left corner because the coordinates are measured from there, and each direction of growth follows from that choice. x grows to the right, so moving across a row increases the first number. y grows downward, so moving down a column increases the second number.

Because every integer pair names exactly one spot and every spot has exactly one integer pair, a point such as (2,1) is never ambiguous once the origin and the two growth directions are fixed. Reading the pair in order also matters: (2,1) and (1,2) name different spots.

Here is what drawing looks like when we trace the grid state. Suppose a program colors three neighboring pixels in one row, starting at the upper left, so that they look like a short horizontal line. Before the drawing call, all three pixels are white. After it, those same three pixels are black. No pixel was added or moved; only the colors of the named pixels changed.

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, and every position you give it is interpreted relative to the rectangle's upper left corner.

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. A drawing call names positions, the graphics context resolves those positions against its rectangle's upper left corner, and the matching pixels are the ones whose colors change.

There is a subtle point to slow 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 lines running across and down the surface. Each integer coordinate names one of those line intersections, and the pixels are the regions between them.