Drawing Shapes with a Graphics Context

Suppose you want a border around a window's drawing area. The obvious approach is to ask for a rectangle exactly as large as the area itself. Before you read on, consider what that choice does to the right and bottom edges. This article traces what the Graphics class actually draws, one step at a time, so you can check your prediction against the model rather than against a memorized rule.

A computer animation is a sequence of individual pictures, each called a frame, shown quickly one after another. Think about a flipbook. Each page holds a slightly different drawing, and when you flip through the pages quickly, the drawings seem to slide, grow, or turn. No single page moves. The motion exists only in the change from one page to the next.

Frame-based animation in a computer works on exactly this principle. The animation is not one object that the program carries around the screen. It is a collection of separate pictures, and each picture is complete in itself. The illusion of motion comes from the relationship between neighboring pictures, which differ only by a small amount. If the change from one picture to the next is small, the viewer perceives one continuous movement. If the change is large, the sequence breaks apart into unrelated images.

A frame-based animation program is organized around a subroutine named drawFrame. The sample program SimpleAnimationStarter.java provides this subroutine as a starting point, and a programmer creates an animation by filling in the body of drawFrame. Each call to drawFrame draws exactly one frame, so drawFrame is the place where each picture is produced.

Besides the graphics context and the width and height of the drawing area, the code inside drawFrame can read two further values. The first is frameNumber, which counts the calls. The second is elapsedSeconds, which records how many seconds the animation has been running. The source pack does not specify how precisely elapsedSeconds is stored, so you should treat it as a value that grows steadily as time passes.

Trace the counter first. frameNumber takes the values 0, 1, 2, 3, and so on in successive calls, increasing by one each time drawFrame runs. Read the diagram as a timeline: each box is one invocation of drawFrame, and the number inside it is the value the program sees on that invocation. Because the counter goes up on every call, the program can use it to decide where a shape should be, how large it should be, or how it should be colored in that particular frame.

The source describes an animation of nested rectangles that shrink toward the center of the drawing. Each frame shows the rectangles slightly smaller than the frame before, so the shapes keep receding inward. The code below is an original illustration of that idea. It is not the source's code, and the exact method signature in the starter program may differ, so check SimpleAnimationStarter.java for the real form. The point is that frameNumber controls how far the rectangle is inset on each call.

The drawFrame subroutine is called about 60 times per second. That fixed rate turns a list of pictures into a moving scene. Because the calls arrive so rapidly, the viewer does not see the individual pictures as separate events. The eye merges them into a single motion.

Frame rate and the size of each change work together. A high frame rate gives many chances per second to show a new picture, while a low frame rate spreads those chances thinly. If the picture changes only slightly between steps, the high-rate version looks smooth. The low-rate version of the same change can appear to jump from one position to the next.

The rectangle method draws the outline of a rectangle. Its upper left corner sits at the point (x, y), and its width and height are the values you pass in. That description is only half the story. The outline is drawn with the same pen used for lines, and that pen colors pixels one pixel to the right of the geometric line and one pixel below it.

The consequence is that the outline's real width is width plus one, and its real height is height plus one. The extra pixel column lies past the right edge, and the extra pixel row lies past the bottom edge. The pixels you see extend one beyond the numbers you typed.

All of the methods discussed here belong to the Graphics class, so each one is called through an object of type Graphics. The examples refer to that object as g, but the programmer chooses the actual name. Each of the four methods takes integer coordinates or sizes, and each parameter has a specific job. The table summarizes what each one controls, following the source's descriptions. The source pack describes drawOval only by name and does not give its parameter meanings in detail, so that row is left to the caption rather than explained further here.

Two details are easy to miss. First, drawString's y value is not the top of the text: some characters, such as the tail of a lowercase y or g, extend below the baseline. Second, a line's coordinates refer to the lines between pixels, and the pen extends one pixel right and down from the point, which is why a single point is not invisible.

Combine the two rules. The rectangle's right column is at x plus width, and the source's one-pixel extra means that column is the one that could fall outside the component. For the right edge to stay visible, that column must be no larger than getWidth() minus 1. The same reasoning gives the bottom edge: y plus height must be no larger than getHeight() minus 1. A rectangle that meets both conditions has its right and bottom edges inside the component.

All of the drawing commands in this group respect the boundaries of the component. Any drawing done outside those boundaries is ignored. This is why the getWidth() minus 1 adjustment matters: pixels placed past the component's right or bottom edge are simply not shown. A shape that fits entirely inside is shown whole, while a shape that extends past an edge shows only the part within the boundary, with the remainder missing.