iOS Drawing: Practical UIKit Solutions (2014)

Filling Paths and the Even/Odd Fill Rule

In vector graphics, winding rules establish whether areas are inside or outside a path. These rules affect whether areas, like those shown in Figure 4-5, are colored or not when you fill a path. Quartz uses an even/odd rule, which is an algorithm that determines the degree to which any area is “inside” a path.

Figure 4-5 An even/odd fill rule establishes whether Quartz fills the entire inner path or only “inside” areas. The shapes on the left side use the default fill rule. The shapes on the right apply the even/odd fill rule.

You use this rule in many drawing scenarios. For example, the even/odd fill rule enables you to draw complex borders. It offers a way to cut areas out of your text layouts so you can insert images. It provides a basis for inverting selections, enabling you to create positive and negative space and more.

The algorithm tests containment by projecting a ray (a line with one fixed end, pointing in a given direction) from points within the path to a distant point outside it. The algorithm counts the number of times that ray crosses any line. If the ray passes through an even number of intersections, the point is outside the shape; if odd, inside.

In the nested square example at the left of Figure 4-5, a point in the very center passes through four subsequent lines before passing out of the path. A point lying just past that box, between the third and fourth inner squares, would pass through only three lines on the way out. Therefore, according to the even/odd fill rule, the first point is “outside” the shape because it passes through an even number of lines. The second point is “inside” the shape because it passes through an odd number.

These even and odd numbers have consequence, which you can see in Figure 4-5. When you enable a path’s usesEvenOddFillRule property, UIKit uses this calculation to determine which areas lay inside the shape and should be filled and what areas are outside and should not.

A special version of the context fill function in Quartz, CGContextEOFillPath(), performs a context fill by applying the even/odd fill rule. When you use the normal version of the function, CGContextFillPath(), the rule is not applied.

Retrieving Path Bounds and Centers

The UIBezierPath class includes a bounds property. It returns a rectangle that fully encloses all points in the path, including control points. Think of this property as a path’s frame. The origin almost never is at zero; instead, it represents the top-most and left-most point, or the control point used to construct the path.

Bounds are useful because they’re fast to calculate and provide a good enough approximation for many drawing tasks. Figure 4-6 demonstrates an inherent drawback. When you’re working with an exacting layout, bounds do not take the true extent of a figure’s curves into account. For that reason, bounds almost always exceed actual boundary extents.

Figure 4-6 The green rendering shows the path. Purple circles are the control points used to construct that path. The dashed rectangles indicate the path’s bounds property (outer rectangle) and the true boundary (inner rectangle). Although close in size, they are not identical, and that difference can be important when you’re creating perfect drawings.

Listing 4-3 turns to the Quartz CGPathGetPathBoundingBox() function to retrieve better path bounds. This approach demands more calculation as the function must interpolate between control points to establish the points along each curve. The results are far superior. You trade accuracy for the overhead of time and processor demands.

The PathBoundingBox() function returns the closer bounds shown in Figure 4-6’s inner rectangle. A related function, PathBoundingBoxWithLineWidth(), extends those bounds to take a path’s lineWidth property into account. Strokes are drawn over a path’s edges, so the path generally expands by half that width in each direction.

Listing 4-3 also includes functions to calculate a path’s center, using both the general (PathCenter()) and precise (PathBoundingCenter()) results. The latter version offers a better solution for transformations, where precision matters. (Slight errors can be magnified by affine transforms.) Using the path bounding box versions of these measurements ensures a more consistent end result.