Drawing Lines and Shapes in Graphics2D

Open almost any drawing program or game and look closely at a diagonal line or a curved outline. On a screen the line is built from small square pixels, and when no special handling is applied the edge of the line can look like a staircase. Programmers call this a jagged or aliased appearance. This article explains how Graphics2D, the Java class used for two-dimensional drawing, can smooth those edges, and how you control that smoothing with a single call.

The central question is simple: if two drawings contain the same shape, why can one look smooth and the other look rough? The answer lies in one setting on the Graphics2D context, and in the order in which your code changes that setting. By the end of this article you should be able to predict which drawing operations a setting affects, and to find the line of code responsible when a drawing does not match what you expected.

A diagonal or curved line is drawn onto a grid of square pixels. Each pixel is a single unit with a single color. Without any special handling, each pixel is either colored by the shape or left alone, so the boundary of the shape ends up as a set of hard, all-or-nothing steps. A pixel that the edge only grazes gets the full shape color just as a pixel the edge fills completely does. That is what produces the staircase.

The source material illustrates this with a picture of several rows of panels. The top row is drawn without antialiasing, and its lines have a visibly jagged edge. The second and third rows are drawn with antialiasing, and their edges look noticeably smoother. The difference between those rows is the subject of the rest of this article.

Read that definition carefully, because each part matters. The drawing color is the color of the shape. The original pixel color is whatever was already on the pixel before the shape was drawn there, such as the background. The blend is a mixture of those two colors. The proportion of the mixture depends on how much of the pixel the shape covers. A pixel that the shape fully covers takes on the shape color. A pixel the shape only touches at a corner takes on mostly the background color. A pixel that the edge splits roughly in half ends up with an intermediate color.

Antialiasing is supported in Graphics2D, but it is turned off by default. If g2 is a Graphics2D context, you turn it on by passing a rendering hint to its setRenderingHint method. A hint has two parts: a key that names the setting being controlled, and a value that says what you want that setting to be. Read the call from left to right. The object g2 is the context whose settings are changing. setRenderingHint is the method that changes one setting. RenderingHints.KEY_ANTIALIASING names the setting that concerns antialiasing. RenderingHints.VALUE_ANTIALIAS_ON gives that setting its enabling value.

To turn antialiasing off, the method name stays the same and the key stays the same. Only the second argument changes to VALUE_ANTIALIAS_OFF. This is the important pattern to remember: because the key and the value are separate arguments, the only difference between turning antialiasing on and turning it off is that second argument. If you find yourself writing a different method name to control antialiasing, you are probably looking at the wrong call.

The effect of the hint is not limited to the call that contains it. Once you set the hint on a Graphics2D context, subsequent drawing operations on that context are likely to be antialiased, and the setting remains in place until you change it again. Earlier operations, performed before the hint was set, are not described as changing. The order of your calls therefore matters: the position of the setRenderingHint call decides which drawings it can influence.

A rendering hint is exactly that: a hint. The call expresses a request, and the system may choose to ignore it. This means that writing setRenderingHint with VALUE_ANTIALIAS_ON does not guarantee that every shape you draw afterward will be smoothed. If your output does not match what the call seems to promise, do not assume the call itself is wrong. The renderer or platform may have chosen not to apply the request.

When a drawing looks wrong, the most useful question is not whether antialiasing exists but where in the code the result stopped matching your expectation. Trace the drawing calls in order. For each one, ask whether the antialiasing hint had been set at that point, and whether the value passed was ON or OFF. The first call where your expectation and the outcome disagree is the place to look.