iOS off-screen rendering optimization

Off-screen rendering (offscreen Render)

Objc.io produced by the Getting Pixels onto the screen of the translation of "draw pixels to the on-screen" should be the domestic screen rendering the concept of the largest promotion of an article. The article mentions that "synthesizing layers directly into a frame's buffer (on the screen) is much cheaper than creating a screen outer buffer, then rendering it to the texture, and finally rendering the result to the frame's buffer." Because this involves two of expensive environmental transformations (the conversion environment to the screen outer buffer, and then the transition environment to the frame buffer). "triggered off-screen rendering occurs after each frame, if there is a large number of off screen rendering occurs when there is a significant impact on the frame rate."

Apple's official information about off-screen rendering was first WWDC in 2011, and it was mentioned in multiple sessions to avoid the effects of triggering off-screen rendering, including: Mask, shadow, group opacity, Edge antialiasing.

It was originally supposed to be from an English developer: using the drawing API in the Core Graphics would also trigger off-screen rendering, such as rewriting DrawRect:. Why a few years ago this kind of understanding is unknown. In WWDC 2011:understanding Uikit Rendering This session demonstrates "core Animation instruments" use "color Word detects off-screen rendering, which is also specifically demonstrated in WWDC 2014:advanced Graphics and animations for IOS Apps.

Core Animation Instruments Debug Options

Designing for Ios:graphics & Performance This article also mentions that using the Core Graphics API triggers off-screen rendering, which leads to Andy Matuschak, the Apple IOS 4.1-8 period Uiki Members of the T Group, WWDC 2011:understanding Uikit Rendering One of the speakers, responded to this view, mainly by saying that "core Graphics's drawing API does trigger off-screen rendering, but not the GPU-less off-screen rendering. The Core Graphics drawing API is executed on the CPU, triggering the off screen rendering of the CPU version. 」

This article takes "color Offscreen-renderd yellow" as the standard for triggering off-screen rendering, unless there is a standard that cannot be detected to trigger off-screen rendering behavior . The Core Graphics API does not trigger off-screen rendering, such as rewriting DrawRect: instead of the above four effects that trigger off-screen rendering, using the rounded corners provided by the system also triggers off-screen rendering, such as:

1 2	View.layer.cornerRadius = 5 View.layer.masksToBounds = True

Fillet optimization Some time ago in the micro-blog brush for a while, do not want to join the fun, but this topic must be talked about.

before you start, lay down something basic.

the relationship between UIView and Calayer

The relationship Between Layers and views of the explanation is meticulous but too verbose, in short, UIView is a package of calayer.

From WWDC 2012:ios App performance:graphics and animations

Calayer is responsible for displaying content contents,uiview providing content and handling events such as touch, and participating in the response chain. The structure of the Calayer is as follows, from Layers Have their Own Background and Border:

Calayer composition

Calayer has three visual elements, and the middle contents attribute declares this: Var contents:anyobject?, in fact it must be a cgimage to display.

When you use let view = UIView (frame:cgrectmake (0, 0, 200, 200)) to generate a View object and add it to the screen, from the Calayer structure, you know that the three visual elements of this view's layer are: content S is empty, background color is empty (transparent color), foreground box width is 0 foreground box, this view can not see anything visually. The first sentence of the Calayer document is: "the Calayer class manages image-based content and allows to perform in that animations The display content of EW is to a large extent a picture (cgimage).

Uiimageview

Since directly to the Calayer contents attribute assignment A cgimage can display the picture, therefore the Uiimageview was born smoothly. In fact, UIImage is a lightweight package for cgimage (or ciimage). I remember when I first contacted IOS, I did not understand the difference between the two, someone said to me, did not think the source is here:

From WWDC 2012:ios App performance:graphics and animations

Uikit and the core Graphics framework are closely related, uikit with the CG prefix properties of the class is basically the corresponding core Graphics framework of the package of objects, uikit in the drawing function is also the core Graphics draw API encapsulation. Drawing with Quartz and Uikit enumerate these correspondence. The content of the interface is mainly image and text, how the text is displayed. It is also drawn using the Core Graphics framework.

Next, formally start the topic of this article.

Roundedcorner

To set rounded corners:

1	View.layer.cornerRadius = 5

What this line of code does. Description of the Cornerradius property in the document:

Setting the radius to a value greater than 0.0 causes the layer to begin drawing rounded in its corners. By default, the corner radius does isn't apply to the image in the layer ' s contents property; It applies only to the background color and border of the layer. However, setting the Maskstobounds property to YES causes the content to be clipped rounded.

Very clear, only the foreground box and background color, and then look at the structure of the Calayer, if the contents content or the content of the background is not transparent, but also need to make this part of the corner out, otherwise the result of the synthesis or not rounded corners, so to modify the Maskstobounds to True (in The corresponding property on the UIView is Clipstobounds, and the corresponding setting in the IB is the "clip subiews" option). The last few days were hilarious. Fillet Optimization article 2 points out that modifying maskstobounds to true rather than modifying Cornerradius is the reason for triggering off-screen rendering, but if you are "color offscreen-renderd yellow"characteristics of the standard words, these two properties are not caused by the separate effect of screen rendering, they are fit (Maskstobounds = True, cornerradius>0) is.

System fillet needs to cut the middle of the layer contents, which the cutting work and off-screen rendering on the performance of the impact of which accounted for a large proportion. I have some questions about that. Although cropping and off-screen rendering cannot be split at the corner of the system, it is possible to independently test the effect of the cropping effort on performance. I use the above mentioned article to optimize the fillet of the Demo provided in the fast scrolling under the frame rate below, based on the verification test:

Base frame rate

The number in parentheses in the figure represents the number of rounded corners on the same screen when scrolling. At the same time, the influence of fillet radius on performance was tested, and there was no significant difference between the two Cornerradius 0.1 and 10 respectively. When using "color offscreen-renderd yellow" to detect, only the rounded corners will have a yellow feature, so the basic observations are not observed at Cornerradius = 0.1. If you have questions about Cornerradius and maskstobounds to trigger off-screen rendering, compare the frame rate to see.

The optimization in this Demo is to redraw the fillet, the author gives his test results on the IPhone 6, very good. The strange thing is that the Demo does not put the work of rounded corners in the background, the article does not explain this, but this Demo in my service for many years in the IPad Mini 1 (IOS 9.3.1) on the results of the operation is not satisfactory, it should be placed in the background redraw and then switch to the main thread set content. To do a comparative test, the front fillet: the main thread to draw rounded corners (Demo optimization method), the background fillet: the original Demo to draw operations to the background thread and then switch to the main thread, the same screen fillet number of 24, compared with the results:

Rounded corner Contrast

The performance of the foreground fillet is slightly better than that of the system fillet, and the background fillet is flat with no rounded corners. After testing, maskstobounds=true and cornerradius>0 have little effect on performance (for rounded corners, foreground rounded corners and background fillet) and cannot observe the yellow features of off-screen rendering at the time of individual action, This means that only the rounded corners of the system trigger off-screen rendering.

Compared to the above test results, see that "in the system fillet (blocking the main thread) cutting work is the main factor affecting performance, the blame should not leave the screen rendering to the back." "The conclusion came. When there is a problem with view performance, it is necessary to distinguish between CPU and GPU, using GPU Driver instruments to detect the bottleneck. The following tests have the same number of rounded corners around 24: