views:

1208

answers:

2

Hi,

I have an application that has three nested views that are mechanically important, but have no visual elements:

  • A vanila UIView that doesn't have any content of its own, and is simply used as a host for CALayers.
  • A UIScrollView (that is queried for it's origin and used to position CALayers in 3d: I really only use this view to faithfully replicate the scroll view's "mechanics"),
  • The scroll view's contents: a UIView subclass. It simply picks up touch events and passes them to a delegate - all that is important are its UIResponder machinery.

The UIView hosting CALayers is a sibling of a UIImageView that is a background image over which the CALayers are drawn.

I'd really like to ensure that none of these empty UIViews have any drawing or compositing overhead (in time, or storage) associated with them, or if that's not possible, to get this overhead as small as possible, and to understand it so that I can perhaps decide if I should try a different approach.

In interface builder, I've set all of the views to not clear their context before drawing. I've not set them to be opaque though, because they definitely are not opaque - they are completely transparent. I've found that I need to give the scroll view contents a transparent clear colour (again in IB by setting the background colour's opacity to zero), and this suggests that it is being drawn, which I don't want.

So, in short, I've not got much idea of what is and isn't getting drawn (anyone know of a tool like Quartz Debug for iPhone / simulator?), or how to go about stopping things from getting drawn.

Advice would be very welcome! Thanks, Benjohn

A: 

Aside from the UIScrollView, which I can't speak for, your other views shouldn't have much in the way of drawing overhead unless you are manually calling setNeedsDisplay or have set their layer's needsDisplayOnBoundsChange property to YES. The views draw once and cache their layers on the GPU at that time. Redrawing is expensive, but that only occurs if you manually trigger it via the means I described above. These views and layers will use memory, so that is a concern, particularly if the enclosing views get very large (especially near the 2048 x 2048 texture limit size). Unfortunately, there's not much you can do about that.

As a suggestion, if all you are doing is rotating and scaling the layers in 3-D, I might suggest that you take a look at some sample code that I had written for doing 3-D rotation and scaling on the iPhone using Core Animation. It's based on code written by Bill Dudney, where touch events are processed into single-touch moves and two-finger pinch gestures and then used to manipulate layers in 3-D. This might simplify your code by removing the need for a UIScrollView and your custom content view.

Brad Larson
In this case, I'm panning the 3D content left and right, but thanks for the link and the other advice in your answer.Can you provide a link that talks about the drawing and caching behaviour of views? That would be very useful.In the end I removed two of the three views by: * Hosting my layers on another view, * Subclassing the scroll view to pick up touch events and pass them to a delegate.
A: 

Actually, you can use Instruments with the Core Animation tool to see what's being drawn (be sure to disable flashing before you quit, because it's a global setting on your device).

David Dunham