Graphics Reference
In-Depth Information
//log
NSLog
(
@"displayed: %i"
,
DEPTH
*
HEIGHT
*
WIDTH
);
}
@end
Figure 15.1
A scrolling 3D matrix of layers
The
WIDTH
,
HEIGHT
, and
DEPTH
constants control the number of layers being generated. In
this case, we have 10×10×10 layers, so 1000 in total, of which only a few hundred will be
visible onscreen at a time.
If we increase the
WIDTH
and
HEIGHT
constants to 100, our app slows down to a crawl. We
now have 100,000 layers being created, so it's not surprising that the performance has
degraded.
But the number of layers that are actually visible onscreen has not increased at all, so
nothing extra is being drawn. The reason the app is now slow is due to the sheer effort of
managing all of those layers. Most of them don't contribute to the rendering effort, but by
forcing Core Animation to calculate the position of each of those layers before discarding
them, we've killed our frame rate.
Because we know that our layers are arranged in a uniform grid, we can determine
mathematically which ones will be visible onscreen without needing to actually create them
or calculate their positions individually. The calculation is nontrivial because it has to take
perspective into account. If we do that work upfront, however, it will save Core Animation
