Graphics Reference
In-Depth Information
After the layers have been successfully packaged up and sent to the render server, the CPU
still has work to do: To display the layers on screen, Core Animation must loop through
every visible layer in the render tree and convert it into a pair of textured triangles for
consumption by OpenGL. The CPU has to do this conversion work because the GPU
knows nothing about the structure of Core Animation layers. The amount of CPU work
involved here scales proportionally with the number of layers, so too many layers in your
hierarchy will indirectly cause additional CPU slowdown every frame , even though this
work takes place outside of your application.
IO-Bound Operations
Something we haven't mentioned yet is IO-bound work. IO (Input/Output) in this context
refers to accessing hardware such as flash storage or the network interface. Certain
animations may require data to be loaded from flash (or even from a remote URL). A
typical example would be a transition between two view controllers, which may lazily load
a nib file and its contents, or a carousel of images, which may be too large to store in
memory and so need to be loaded dynamically as the carousel scrolls.
IO is much slower than normal memory access, so if your animation is IO-bound that can
be a big problem. Generally, this must be addressed using clever-but-awkward-to-get-right
techniques such as threading, caching, and speculative loading (loading things in advance
that you don't need right now but predict you will need in the future). These techniques are
discussed in depth in Chapter 14.
Measure, Don't Guess
So, now that you know where the slowdown points might be in your animation, how do you
go about fixing them? Well, first of all, you don't . There are many tricks to optimize an
animation, but if applied blindly, these tricks often have as much chance of causing
performance problems as correcting them.
It's important to always measure rather than guess why your animation is running slowly.
There is a big difference between using your knowledge of performance to write code in an
efficient way, and engaging in premature optimization . The former is good practice, but the
latter is a waste of time and may actually be counterproductive.
So, how can you measure what's slowing down your app? Well, the first step is to make
sure you that are testing under real-world conditions.
 
Search WWH ::




Custom Search