视图（或图层）何时需要屏幕外渲染？ [英] When does a view (or layer) require offscreen rendering?

问题描述

您好本周末我开始观看2011年WWDC视频。我发现了关于iOS的非常有趣的话题。我的最爱是关于性能和图形，但我发现其中两个显然是矛盾的。当然有一些我没有得到的东西。
我正在谈论的会议是了解UIKit渲染-121和抛光你的应用-105。


不幸的是，2011年的示例代码仍然无法下载，因此很难获得整体视图。
在一个会话中，他们解释说，在scrollview等可视化期间，大多数时候应该避免屏幕外渲染。他们修复了示例代码中的性能问题，几乎在-drawRect方法中绘制了所有内容。
在另一个会话中，性能问题（在表视图上）似乎是由于表格单元格的-drawRect方法中的代码太多。

首先我不清楚系统需要一个OffScreen渲染，我在视频中看到一些石英功能，如：cornerRadious，shadowOffset，shadowColor需要它，但确实存在一般规则？

其次我不知道知道我是否理解得很好，但似乎没有屏幕外渲染添加图层或视图是要走的路。
我希望有人可以说明这一点..

谢谢，

Andrea

解决方案

我不认为在任何地方写下了规则，但希望这会有所帮助：

首先，让我们澄清一些定义。我认为屏幕外渲染与屏幕渲染在大多数情况下并不是最重要的问题，因为屏幕外渲染可以像在屏幕上一样快。主要问题是渲染是在硬件还是软件中完成的。

使用图层和视图之间的实际差异也很小。视图只是CALayer的一个薄包装，它们在大多数情况下不会引入显着的性能损失。如果您希望使用CAShapeLayer或CATileLayer等支持的视图，则可以使用+ layerClass方法覆盖视图使用的图层类型。

一般情况下，打开iOS，像素效果和Quartz / Core Graphics绘图不是硬件加速的，大多数其他东西都是。

以下内容不是硬件加速，这意味着他们需要在软件中完成（屏幕外）：

1. 在drawRect中完成的任何事情。如果你的视图有一个drawRect，即使是一个空的，它也不会在硬件中完成，并且会有性能损失。




2. 任何带有shouldRasterize的图层属性设置为YES。




3. 任何带有蒙版或阴影的图层。




4. 文本（任何类型，包括UILabels，CATextLayers，核心文本等）。




5. 您使用CGContext自己（在屏幕上或屏幕外）进行的任何绘图。 / p>

大多数其他东西都是硬件加速的，所以速度要快得多。但是，这可能并不意味着你的想法。

与硬件加速绘图相比，上述任何类型的绘图都很慢，但它们并不一定会减慢你的应用程序，因为它们不需要每帧发生。例如，第一次在视图上绘制投影时速度较慢，但​​在绘制之后会缓存，只有在视图更改大小或形状时才会重绘。

<对于使用自定义drawRect的光栅化视图或视图也是如此：视图通常不会每帧重绘，它被绘制一次然后缓存，因此首次设置视图后的性能不会更糟，除非边界更改或你调用setNeedsDisplay。

为了获得良好的性能，诀窍是避免使用软件绘图来改变每一帧的视图。例如，如果您需要动画矢量形状，使用CAShapeLayer或OpenGL比使用drawRect和Core Graphics获得更好的性能。但是如果你画一次形状然后不需要改变它，它就不会有太大的区别。

同样，不要在上面放一个投影动画视图，因为它会降低帧速率。但视图上的阴影不会在帧与帧之间发生变化，不会产生太大的负面影响。

需要注意的另一件事是减慢视图设置的速度时间。例如，假设您有一页文本，所有文本都有阴影;这将需要很长时间才能绘制，因为文本和阴影都需要在软件中渲染，但一旦绘制它将会很快。因此，您需要在加载应用程序时提前设置此视图，并将其保留在内存中，以便用户不必等待视图在屏幕上首次显示时显示。

这可能是WWDC视频中明显矛盾的原因。对于不改变每一帧的大型复杂视图，在软件中绘制一次（之后将它们缓存并且不需要重新绘制）将比使硬件每帧重新组合它们产生更好的性能，即使第一次绘制会比较慢。

但对于必须不断重绘的视图，如表格单元格（单元格被回收，因此每次都必须重绘它们单元格在屏幕外滚动并重新使用，因为它向后滚动到另一侧作为不同的行），软件绘图可能会减慢很多事情。

Hello
this weekend I started to watch the 2011 WWDC videos. I've found really interesting topics about iOS. My favorites were about performance and graphics, but I've found two of them apparently in contradiction. Of course there is something that I didn't get. The sessions that I'm talking about are Understanding UIKit Rendering -121 and Polishing your app -105.
Unfortunately sample code from 2011 is still not downloadable, so is pretty hard to have an overall view. In one session they explain that most of times offscreen rendering should be avoided during visualization in scrollview etc. They fix the performance issues in the sample code almost drawing everything inside the -drawRect method. In the other session the performance issue (on a table view) seems to be due to too much code in the -drawRect method of the table's cells.
First is not clear to me when an OffScreen rendering is required by the system, I've seen in the video that some quartz function such as: cornerRadious, shadowOffset, shadowColor requires it, but does exist a general rule?
Second I don't know if I understood well, but it seems that when there is no offscreen rendering adding layers or views is the way to go. I hope someone could bring light about that..
Thanks,
Andrea

解决方案

I don't think there is a rule written down anywhere, but hopefully this will help:

First, let's clear up some definitions. I think offscreen vs onscreen rendering is not the overriding concern most of the time, because offscreen rendering can be as fast as onscreen. The main issue is whether the rendering is done in hardware or software.

There is also very little practical difference between using layers and views. Views are just a thin wrapper around CALayer and they don't introduce a significant performance penalty most of the time. You can override the type of layer used by a view using the +layerClass method if you want to have a view backed by a CAShapeLayer or CATileLayer, etc.

Generally, on iOS, pixel effects and Quartz / Core Graphics drawing are not hardware accelerated, and most other things are.

The following things are not hardware accelerated, which means that they need to be done in software (offscreen):

1. Anything done in a drawRect. If your view has a drawRect, even an empty one, the drawing is not done in hardware, and there is a performance penalty.

2. Any layer with the shouldRasterize property set to YES.

3. Any layer with a mask or drop shadow.

4. Text (any kind, including UILabels, CATextLayers, Core Text, etc).

5. Any drawing you do yourself (either onscreen or offscreen) using a CGContext.

Most other things are hardware accelerated, so they are much faster. However, this may not mean what you think it does.

Any of the above types of drawing are slow compared to hardware accelerated drawing, however they don't necessarily slow down your app because they don't need to happen every frame. For example, drawing a drop shadow on a view is slow the first time, but after it is drawn it is cached, and is only redrawn if the view changes size or shape.

The same goes for rasterised views or views with a custom drawRect: the view typically isn't redrawn every frame, it is drawn once and then cached, so the performance after the view is first set up is no worse, unless the bounds change or you call setNeedsDisplay on it.

For good performance, the trick is to avoid using software drawing for views that change every frame. For example, if you need an animated vector shape you'll get better performance using CAShapeLayer or OpenGL than drawRect and Core Graphics. But if you draw a shape once and then don't need to change it, it won't make much difference.

Similarly, don't put a drop shadow on an animated view because it will slow down your frame rate. But a shadow on a view that doesn't change from frame to frame won't have much negative impact.

Another thing to watch out for is slowing down the view setup time. For example, suppose you have a page of text with drop shadows on all the text; this will take a very long time to draw initially since both the text and shadows all need to be rendered in software, but once drawn it will be fast. You will therefore want to set up this view in advance when your application loads, and keep a copy of it in memory so that the user doesn't have to wait ages for the view to display when it first appears on screen.

This is probably the reason for the apparent contradiction in the WWDC videos. For large, complex views that don't change every frame, drawing them once in software (after which they are cached and don't need to be redrawn) will yield better performance than having the hardware re-composite them every frame, even though it will be slower to draw the first time.

But for views that must be redrawn constantly, like table cells (the cells are recycled so they must be redrawn each time one cell scrolls offscreen and is re-used as it scrolls back onto the other side as a different row), software drawing may slow things down a lot.

这篇关于视图（或图层）何时需要屏幕外渲染？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！