Shapes and Outlines with drawRect and drawOval

Suppose you draw a diagonal line or the outline of an oval in a Java graphics program and the result looks rough. Instead of a smooth slope or curve, the edge appears as a set of small steps. It is natural to suspect the drawing call itself, but the call is often not the problem. The difficulty comes from the surface you are drawing on, which is a grid of pixels, and a smooth geometric edge rarely lines up exactly with that grid.

The name for the jagged look is aliasing. It appears when shapes are drawn using pixels. A pixel is either colored or not colored at a given position. There is no partly colored pixel in this basic model, so a slanted edge must be represented by a staircase of whole pixels. The eye reads that staircase as roughness.

Read the grid row by row. Each row has to commit to whole pixels, so the on region steps down and to the right instead of forming one continuous slanted line. Each individual step is small, but the eye notices the pattern. That is the stair-step effect you see on rough diagonals and oval outlines.

Antialiasing is the technique that tries to reduce this roughness. Instead of treating an edge as a hard boundary between colored and uncolored pixels, the rendering process blends the boundary pixels so that the transition looks smoother. The practical results are that diagonal lines and oval outlines look much cleaner, and text can also look better.

Antialiasing is enabled through a rendering hint set on the graphics context. A rendering hint is a request that tells the drawing system how to handle a certain aspect of rendering. The hint for antialiasing uses a key, which names the aspect being controlled, and a value, which says whether it is on or off. To turn antialiasing on, you set the antialiasing key to the on value on the graphics context, which this article calls g2.

Read the statement from left to right and it names exactly what it does: it sets a rendering option on g2, the option is antialiasing, and the chosen setting is on. The setting belongs to the context. It is a property of how g2 draws, not something attached to one particular shape. That is why the position of the call in your program matters.

Stroke width is the thickness of the lines used to draw shapes. The thickness is set by creating a BasicStroke object and handing it to the graphics context through setStroke. The value passed to the BasicStroke constructor can be an integer or a floating-point number, and it becomes the width that subsequent lines will have.

The rule also covers outlined shapes. The thickness affects the outlines of shapes drawn with methods such as drawRect and drawOval, so a width change alters the border of those shapes, not their fill. This is the reason an outline can look thicker in one place in your program and thinner in another, even though the shape call looks identical.

Because the stroke setting is part of the graphics context, the easiest way to predict its effect is to trace the state as the calls run in order. Think of the context as holding a current stroke width. Each setStroke call replaces it, and each outline drawn afterward uses whatever value is current at that moment.

When a drawing does not match what you expected, do not start by rewriting shape code. Instead, list the calls that touch the graphics context in the order they execute. For each outline or edge, ask which settings were in effect at the moment it was drawn. The cause of the difference usually shows up at one specific call, and that call is where the investigation should end.

A useful way to confirm the cause is to draw the same outline twice in one program, changing only the presence or position of one setting, and then compare the results. This keeps the investigation grounded in what the program actually renders rather than in an assumption about how the settings interact.