Tuning for Speed - iOS Core Animation - page 254

render the layer offscreen. That doesn't mean that you need to avoid these effects
altogether, just that you need to be aware that they can have a performance impact.
▪ Too-large images —If you attempt to draw an image that is larger than the maximum
texture size supported by the GPU (usually 2048×2048 or 4096×4096, depending on
the device), the CPU must be used to preprocess the image each time it is displayed,
slowing the performance right down.
CPU-Bound Operations
Most of the CPU work in Core Animation happens upfront before the animation begins.
This is good because it means that it generally doesn't impact the frame rate, but it's bad
because it can delay the start of an animation, making your interface appear unresponsive.
The following CPU operations can all slow down the start of your animation:
▪ Layout calculations —If your view hierarchy is complex, it might take a while to
calculate all the layer frames when a view is presented or modified. This is especially
true if you are using iOS 6's new autolayout mechanism, which is more CPU-
intensive than the old autoresizing logic.
▪ Lazy view loading —iOS only loads a view controller's view when it is first
displayed onscreen. This is good for memory usage and application startup time, but
can be bad for responsiveness if a button tap suddenly results in a lot of work having
to be done before anything can appear onscreen. If the controller gets its data from a
database, or the view is loaded from a nib file, or contains images, this can also lead
to IO work , which can be orders of magnitude slower than ordinary CPU operations
(see the “IO-Bound Operations” section, later in this chapter).
▪ Core Graphics drawing —If you implement the -drawRect: method of your view,
or the -drawLayer:inContext: method of your CALayerDelegate , you introduce a
significant performance overhead even before you've actually drawn anything. To
support arbitrary drawing into a layer's contents, Core Animation must create a
backing image in memory equal in size to the view dimensions. Then, once the
drawing is finished, it must transmit this image data via IPC to the render server. On
top of that overhead, Core Graphics drawing is very slow anyway, and not something
that you want to be doing in a performance critical situation.
▪ Image decompression —Compressed image files such as PNGs or JPEGs are much
smaller than the equivalent uncompressed bitmaps. But before an image can be drawn
onscreen, it must be expanded to its full, uncompressed size (usually this equates to
image width × height × four bytes). To conserve memory, iOS often defers decom-
pression of an image until it is drawn (more on this in Chapter 14, “Image IO”).
Depending on how you load an image, the first time you assign it to a layer's
contents (either directly or indirectly by using a UIImageView ) or try to draw it into
a Core Graphics context, it may need to be decompressed, which can take a
considerable time for a large image.