Exactly what performance-critical things should I have an eye out for?
I want a list with as many examples as possible. Or a list of best practices.
Offscreen rendering / Rendering on the CPU
The biggest bottlenecks to graphics performance are offscreen rendering and blending – they can happen for every frame of the animation and can cause choppy scrolling.
Offscreen rendering (software rendering) happens when it is necessary to do the drawing in software (offscreen) before it can be handed over to the GPU. Hardware does not handle text rendering and advanced compositions with masks and shadows.
The following will trigger offscreen rendering:
Any layer with a mask (layer.mask)
Any layer with layer.masksToBounds / view.clipsToBounds being true
Any layer with layer.allowsGroupOpacity set to YES and layer.opacity is less than 1.0
When does a view (or layer) require offscreen rendering?
Any layer with a drop shadow (layer.shadow*).
Tips on how to fix: https://markpospesel.wordpress.com/tag/performance/
Any layer with layer.shouldRasterize being true
Any layer with layer.cornerRadius, layer.edgeAntialiasingMask, layer.allowsEdgeAntialiasing
Any layer with layer.borderWith and layer.borderColor?
Missing reference / proof
Text (any kind, including UILabel, CATextLayer, Core Text, etc).
Most of the drawings you do with CGContext in drawRect:. Even an empty implementation will be rendered offscreen.
Blending
resizableImage can cause blending.
Avoiding blended layers when using resizableImages on iOS
Any layer which is not opaque and has a backgroundColor with alpha less than 1.0
Any layer with alpha less than 1.0
Any layer with layer.content or any UIImageView with a UIImage having an alpha channel
Layout
The following things will trigger layoutSubviews to be called on a UIView:
Changing bounds triggers on the same view and superview
Changing frame triggers on the same view and superview
Changing transform or layer.transform triggers on superview
Note: I'm referring to real changes where values actually are changing
Contradictory these changes does not trigger layoutSubviews to be called: center, layer.position, layer.zPosition, layer.anchorPoint, layer.anchorPointZ.
Reference: https://github.com/hfossli/LayoutSubviewsInconsistency
General tips for improving performance
Oftentimes it is better to blend than to render offscreen.
Consider using drawRect: instead of having a view with multiple labels and subviews.
Draw on a background queue to a UIImage or CGImageRef.
Draw to a CGLayer (which is cached better on GPU compared to UIImage), and draw whatever you want into it.
Update, don't: http://iosptl.com/posts/cglayer-no-longer-recommended/
Flatten your hierarchy
Reuse views – don't create and add new ones while scrolling
Have opaque views with solid background color
Avoid setting alpha and layer.opacity to less than 1.0
Enable layer.shouldRasterize (use with care). I like to avoid this personally, but it performs faster in some occasions since rasters of the layer will be cached and reused. Remember if you enable shouldRasterize on layers that changing their content or sublayers contents frequently will cause the performance to drop, since iOS will keep rasterizing the layer on each change.
Links
http://iosinjordan.tumblr.com/post/56778173518/help-my-tables-dont-scroll-smoothly
https://developer.apple.com/library/IOS/documentation/2DDrawing/Conceptual/DrawingPrintingiOS/DrawingTips/DrawingTips.html
Related
If I set shouldRasterize = YES on a CALayer, do I have to set it on each of the sublayers as well if I wanted the whole hierarchy to be flattened for better animation performance?
I'm asking because when I set shouldRasterize = YES on my root layer and enable "Color Blended Layers" in Instruments, all the sublayers are still there and marked as blended. It's not flattening anything.
Setting shouldRasterize does not do quite what you are thinking it does. In order to composite the look of the parent view, rasterized or not, it has to check subviews to see if they are opaque or transparent. When child objects are opaque, they do not need to be blended. When they are transparent, the view needs to be blended with whatever is behind them (or higher in the hierarchy).
So, shouldRasterize will not affect the green/red you see using Instruments. In order to have everything green, you'll need to not use transparency and have all your child objects be opaque. Sometimes its unavoidable to still have red areas depending on your design. The instrument is just there to help you optimize ones that could be opaque and reduce the amount of blending the GPU has to do.
Edit:
To explain further, suppose you have a UILabel and its sitting on top of a photo. You only want to see the text and not its background color, so you set its backgroundColor to clear, and the opaque property to NO. In instruments, this will now appear red. The GPU has to blend this transparency over the image behind it, performing two draw operations instead of one.
If we had set opaque to YES and gave it a solid background color, the view would now show up green in instruments because it didn't have to blend that view with any other view.
So, whether the layer is rasterized or not, it still has to composite its child views so shouldRasterize really has no effect either way on what you see in Instruments.
I have an EAGLView which I am resizing in an animation, with the animation driven by an NSTimer that calls a draw function. As I resize the EAGLView, I need to adjust the projection for the view to maintain the aspect ratio of the contents. The draw function looks like this:
gameView.frame = newFrame;
[gameView setFramebuffer];
[self updateProjection];
/* Drawing to the EAGLView, gameView, here, then... */
[gameView presentFramebuffer];
Run like this, though, the contents of the EAGLView appear to "stair-step" down the animation. When I record it and look at it frame by frame, it's clear that the projection is adjusted, then the view is resized a very short time later (less than one animation frame).
I suspect that the reason is that the change in the frame of gameView is being deferred, and that in the meantime the updated framebuffer is making its way to the screen. I've tried using CATransactions to get the frame update to take effect immediately, but as I kind of expected for a UIView change, that did nothing. I suppose I could modify the viewport and leave the EAGLView full-frame, but I worry that that might just leave me with synchronization issues elsewhere (say, with updates to any overlaid CALayers).
Does this seem like a reasonable assessment of the problem? How can I prevent it -- that is, how can I best ensure that the framebuffer presentation coincides with the change in the actual frame of the EAGLView (and other CA elements)?
Thanks!
I encountered a similar issue with a custom EAGLView I wrote. The problem was that when changing orientation, the view got resized and the contents stretched, and only after the animation, the scene with the right proportions was displayed.
I think yours is the same problem, and I don't think you can force CoreAnimation to wait for your view to update before rendering an animation frame, because of the way it works (CA isn't aware of the drawing mechanism of the view or the layer on which operates).
But you can easily bypass the problem: open you xib file containing the view, switch to the attributes inspector on the right. Select your EAGLView (the same applies to GLKView), and under the section View there's the Mode attribute. If you're creating the view programmatically, set the contentModeproperty.
This value describes how the view contents are managed during an animation. Until the buffer is displayed, the old scene gets resized according to that mode; perhaps you can find a mode that fits the animation you need to achieve.
If you're worried about proportions, the center content mode may work, but the part of scene that hasn't been rendered yet will appear empty during the animation.
Unfortunately the redraw mode won't necessarely make your EAGLView refresh: the view is actually redrawn, but potentially with the old contents of the color buffer. It's a problem of getting the buffer filled at the right time.
You could try to resize and prerender a frame big enough to cover the whole animation before starting it; or you could try to render a frame to an UIImage, replace the view on the fly, animate it, the place the EAGLView back, but this may seriously affect performance.
The way I solved my issue was making simply the EAGLView big enough.
Regarding the blending of other CALayers, as far as I tried, I encountered no synchronization issue; the EAGLView updates when it can, and the other layers too. Just set the right properties to CAEAGLLayer if you're using alpha channel, and rememeber that blending the layers every time OpenGL updates your scene may be expensive in terms of performance.
I make extensive use of -drawRect: to do some nice animations. A timer tries to fire 30 times per second with -setNeedsDisplay, but it feels like just 20 times. Also I can't use -setNeedsDisplayInRect: because the animation covers the entire thing.
Would it help to take some of those drawing operations out of -drawRect: and move them to a subview? -drawRect has to do less then, but instead the OS will have more work with compositing views.
Is there a rule of thumb which one is more worse? I remember from an apple text that they claimed Core Animation doesn't redraw during animation. So is that their secret of speed? Using subviews in animations?
Much of this will be similar to my answer to your other question:
Compositing is faster, by far. On the iPhone, content is drawn into a CALayer (or into a UIView's backing CALayer) using Quartz drawing calls or from a bitmapped image. This layer is then rasterized and effectively cached as an OpenGL texture on the GPU.
This drawing and caching operation is very expensive, but once the layer is on the GPU, it can be moved around, scaled, rotated, etc. in a hardware-accelerated manner. All the GPU has to do while the layer is animating is to composite it with the other onscreen layers every frame. This is why Core Animation can do 50 layers animating around the screen at 60 FPS on even the oldest iPhone models.
Layers and views only redraw themselves when prompted, or if resized when their needsDisplayOnBoundsChange property is set to YES. The drawing system is set up this way because of how expensive it is to redraw and recache the layer contents. If you can, avoid redrawing your layer content regularly, but instead split it into layers or views that you can animate around individually using Core Animation. If you need to animate a changing shape, look to CAShapeLayer, which makes this much more efficient than simply redrawing every frame.
As a worst case, yes, you can take the portions of your view that are static and move them to one view, then have a subview which has only the changing portion of your drawing within it. Performance won't be great, but it will be much better than if you had to redraw everything within the view. Compositing overhead will be negligible compared to the expense of drawing.
I have a UIView with a large number of CALayers (~1000), each of which has a small image as its contents. This UIView is a subview of a scrollview (actually it's a subview of another view which is a subview of the scrollview). This draws relatively quickly at first (couple seconds). However when I scroll in the scrollview the frame rate is very low.
Is it trying to redraw the contents of each CALayer every time I scroll? Is there a way to disable this? Is something else going on?
Note: I set clearsContextBeforeDrawing to NOo n my UIView and this helped somewhat but it's still much slow than I would expect
The layers should not be redrawn, but they will be composited using the GPU. Try using the Sampler and OpenGL ES instruments in Instruments to see if your bottleneck is in the CPU or GPU. You can log extra detail within the OpenGL ES instrument by tapping on the "i" next to the instrument name and selecting the extra parameters (Tiler Utilization, Renderer Utilization, etc.). If one of the OpenGL values is near 100%, then it's the compositing that's holding you back. However, if the sampler is showing a number of calls to -drawRect: or similar methods, then your layers are being redrawn (for some reason) and that could be the problem.
Additionally, you can use the Core Animation instrument to color non-opaque layers, which can lower your display framerate.
Set the needsDisplayOnBoundsChange property on your layers to NO:
[layer setNeedsDisplayOnBoundsChange:NO];
The documentation says that the clipsToBounds property of UIView will clip the drawing to the bounds, or more precisely that the subView can't draw outside of the bounds of the superView.
Sounds nice, but what does that mean in practice?
If I set that to YES, then my subView will automatically only draw those parts which are not outside the bounds of the superView. so it increases the overall performance or do I still have to make sure that I don't create any views that are not visible, i.e. inside a UIScrollView ?
I think it's the opposite: turning on clipping hurts performance because it has to set up a clipping mask. I vaguely remember reading this somewhere, but I can't find it now.
The use case for clipsToBounds is more for subviews which are partially outside the main view. For example, I have a (circular) subview on the edge of its parent (rectangular) UIView. If you set clipsToBounds to YES, only half the circle/subview will be shown. If set to NO, the whole circle will show up. Just encountered this so wanted to share.
The (possible) performance hit is only deterministic if you know the view hierarchy. As mentioned above, usually the renderer will use GPU cycles to draw the view UNLESS some view within the hierarchy uses drawRect:. This does not affect OpenGL ES application because drawRect:is omitted in this type of apps.
From my understanding, determining and displaying the clipped area may take less cycles than actually calculating/drawing/blending the whole view. As of OpenGL ES 2.0 clipping can be calculated in GPU.