iOS Drawing: Practical UIKit Solutions (2014)

Chapter 1. Drawing Contexts

Drawing contexts are the virtual canvases you draw into from your applications. In this chapter, you review core technologies that underlie iOS drawing. You dive into contexts, discovering how to build and draw into them. You use contexts to create images, documents, and custom views, learning about basic drawing fundamentals in UIKit, Core Graphics, and Quartz.

Frameworks

iOS’s drawing routines are primarily sourced from the UIKit and QuartzCore frameworks. They consist of a mix of modern Objective-C interfaces (from UIKit) along with older C-based functions and Core Foundation-style objects (from QuartzCore). These items live side by side in your code. Here’s an example that shows a UIKit drawing operation followed by a Quartz one:

// Draw a rounded rectangle in UIKit
UIBezierPath *bezierPath =
[UIBezierPath bezierPathWithRoundedRect:inset cornerRadius:12];
[bezierPath stroke];

// Fill an ellipse in Quartz
CGContextFillEllipseInRect(context, rect);

The QuartzCore framework is commonly referred to as Quartz or Quartz 2D. The latter is Apple’s official name for its native 2D rendering and antialiasing API. It’s also the name used for the primary drawing reference in Apple’s developer library, the “Quartz 2D Programming Guide.”

The reach of this framework is wider than the Quartz 2D name might suggest. The QuartzCore framework implements compositing as well as rendering, along with many other graphics features. For example, the QuartzCore APIs include animation, tiling, and Core Image filtering (even though Core Image is properly its own framework).

To iOS developers, Quartz is often better known by its internal implementation name, Core Graphics. This book uses the terms Quartz and Core Graphics synonymously throughout. Most of the C-based APIs start with the two-letter CG prefix, derived from the Core Graphics name. From geometry (CGRect and CGPoint) to objects (CGColorRef, CGImageRef, and CGDataProviderRef), Quartz offers a vast, rich trove of drawing technology.

Quartz and its predecessors have been around for a long time. Contributing elements date back to the 1980s, when Display PostScript powered the graphics on the NeXTStep operating system. Quartz still uses an internal imaging model that’s very similar to modern PDF.

With each iOS release, updates continue to move the drawing APIs further toward Objective-C, simplifying, enhancing, and refining programmatic drawing. Core Graphics functions, however, continue to play an important role in day-to-day drawing development. Although newer routines replace many common tasks, they haven’t supplanted them all. Be prepared to work with both frameworks for the foreseeable future.

When to Draw

Although iOS drawing is a fairly common task for developers, the task itself is not very general. Most drawing is limited to certain specific arenas, namely four extremely common scenarios where it makes sense to work directly with graphics: creating custom views, building images, creating PDFs, and building with Core Graphics.

Creating Custom Views

Every UIKit view is, essentially, a blank canvas. You can fully customize a view by drawing whatever contents best express the view’s role in your application. You do this by drawing that content in a special method called drawRect:. This method enables you to customize a view’s look by calling UIKit and Quartz drawing routines.

Figure 1-1 shows a custom color control. It consists of a deck of swatch views, each of which is a UIView subclass that implements the drawRect: method. These views draw the border with its rounded edges, the informational text, and the splash of color to create a fully realized, yet fully custom, look.

Figure 1-1 These swatches are drawn by custom drawRect: methods.

Unless you override it in a subclass, the default drawRect: method basically does nothing. Subclasses that create a presentation using UIKit and Core Graphics routines override this method. They add their drawing requests to their subclass implementation. Simple views that merely update a background color or that supply content in other ways apart from drawing should not override drawRect:. Similarly, OpenGL ES-powered views do not use this entry point for drawing.

The drawRect: method has a close cousin that is meant only for printing: drawRect:forViewPrintFormatter: allows you to customize content that should print differently than it displays.

Building Images

Not every image starts its life as a PNG or JPEG file. On iOS, you can draw into a UIKit image context and retrieve a UIImage instance. This enables you to create new images or modify existing images.

Figure 1-2 shows a programmatically constructed color wheel. This image was created via a series of colored Bezier path arcs drawn into a UIKit image context. The resulting image was then added to a standard image view. Drawing allows you to build custom images as you need them without having to rely on a preexisting library of image files.

Figure 1-2 This color wheel was built from code into a custom UIImage.

Code-based drawing makes an important trade-off. Although you need greater processing time to create images (not a huge amount, but its measurable), you end up with a slimmer application bundle, with fewer required resources. Your images are far more flexible—limited only to the code you use to create them.

Creating PDFs

The same kinds of calls that help you build images also support PDF creation. You can draw into a UIKit PDF context, which is either sent directly to a file or saved to data. This enables you to build PDF content from your apps and then share them, store them, or display them, as in Figure 1-3.

Figure 1-3 A multipage PDF is previewed in this iOS 6 popover.

PDFs provide a highly portable, system-independent standard that encapsulates a complete document description. The document you create on iOS looks the same, more or less, on any computer you use to view it. The operating system’s color management system may affect color presentation.

Building with Core Graphics

When you hit the edges of UIKit’s current capabilities, you can fall back to standard Quartz. Core Graphics has been around a long time, and its drawing features have powered OS X for a decade. Any feature that isn’t immediately tweakable in UIKit is almost always available through Quartz.

Drawing items into a Core Graphics context provides flexible and powerful drawing solutions—even if they’re not quite as simple as their UIKit siblings. Core Graphics uses Core Foundation-style C-based objects and requires manual retain and release development strategies.

For example, you might want to access image data on a byte-by-byte level. That’s a task that isn’t well handled by UIKit (yet!) but is perfect for Core Graphics’s bitmap contexts. Figure 1-4 shows an example of why you might turn to Quartz functions. In this example, the RGB image on the left is rendered into a grayscale color space using Core Graphics.

Figure 1-4 The routine that transformed this RGB image to a grayscale representation was written using Core Graphic primitives.

The resulting images must be transformed from Quartz CGImageRef (CG types that end with Ref are pointers to objects) into UIImage instances (imageWithCGImage:) and displayed in a standard image view.

Contexts

Every iOS drawing operation begins with a context. Conceptually, contexts are very similar to blank pages of paper or empty canvases. They represent an iOS destination for drawing. They contain all the information about the state of the drawing medium—for example, whether the canvas is rotated or transformed in some way, what kind of colors can be drawn onto the canvas, the degree of detail you can paint at any point, and so forth.

In iOS, you primarily work with two kinds of drawing contexts: bitmap contexts and PDF contexts. The Core Image framework offers a third context type, which is used for performing image processing tasks rather than drawing.

Bitmap Contexts

Bitmap contexts are essentially rectangular arrays of data. The size of that data depends on the kinds of color each picture element (or “pixel”) represents. Device RGB, as shown in the left image of Figure 1-4, uses three or four bytes per pixel, depending on whether the bitmap is opaque (3 bytes) or not (4 bytes).

An opaque bitmap ignores translucency values, optimizing storage. Translucent images use what’s called an alpha value. This value is stored in a separate byte from the actual color or luminance information. It refers to each pixel’s translucency. The color information for Device RGB is stored in 3 bytes, each corresponding to a single red, green, or blue level.

Device Gray images, as shown on the right in Figure 1-4, use 1 or 2 bytes per pixel. One luminance byte is stored for each pixel and, optionally, one transparency byte.

PDF Contexts

From a developer’s point of view, PDF contexts work in much the same way as bitmap contexts. You draw to them using identical commands and functions. You set colors and draw shapes and text just as if you were drawing in a view or to an image. There are, however, differences.

PDF contexts contain vector data in their “backing store,” describing the drawing in a resolution-independent manner. Bitmap contexts are rasterized. They use pixel arrays to store the data drawn into them.

PDF contexts also may contain more than one page. You establish a bounding rectangle that specifies the default size and location of each PDF page. An empty rectangle (CGRectZero) defaults to a standard A (letter) page. That is 8.5 by 11 inches, or 612 by 792 points. (Chapter 2 discusses the difference between points and pixels.)

PDF drawings are stored internally as vector-based command sequences. This provides an inherent resolution independence that you don’t see in bitmap drawings. Apple writes in its documentation, “PDF files are resolution independent by nature—the size at which they are drawn can be increased or decreased infinitely without sacrificing image detail. The user-perceived quality of a bitmap image is tied to the resolution at which the bitmap is intended to be viewed.”

You draw into these contexts just like you’d draw into bitmap contexts. The differences primarily lie in their destination (files and data representations) and when you start a new page.

In addition to bitmap and PDF contexts, you may also encounter Core Image contexts.

Core Image Contexts

The Core Image framework helps you process images extremely quickly. It supplies routines that apply digital image processing and computer vision to image sources. With it, you can apply filters, chain filters together, implement feature detection (to find faces and eyes), and analyze images to produce auto-adjustments.

Core Image contexts are image contexts specific to rendering Core Image objects to Quartz 2D and OpenGL. Accelerated by the onboard graphics processing unit (GPU), Core Image contexts integrate with Core Video pixel buffers. Core Image uses its own style of colors (CIColor) and images (CIImage), which have been optimized for Core Image’s fast filtering and image processing features.

Establishing Contexts in UIKit

UIKit provides friendly entry points for building contexts. The simplest image drawing pattern is shown in Listing 1-1. This involves nothing more than starting a new context (you specify the size of that context), drawing to it, retrieving a new image, and ending the context. This pattern produces images at a base 1:1 scale, where every drawing operation corresponds to exact pixels within the bitmap context.

Listing 1-1 Creating a Basic Bitmap Context in UIKit