objc中国#3 绘制像素到屏幕上 阅读笔记

1.绘制像素到屏幕上

软件的组成

7D34011B-CF95-460B-8035-62F9853E4DD2.png

GPU :图形处理单元。更多图像的绘制
CPU:图形高迸发计算而量身定做的处理单元。更对为绘制图像提供计算、数据。
GPU Driver: 是直接和 GPU 交流的代码块。不同的GPU是不同的性能怪兽，但是驱动使他们在下一个层级上显示的更为统一，典型的下一层级有 OpenGL/OpenGL ES.
OpenGL(Open Graphics Library): 是一个提供了 2D 和 3D 图形渲染的 API。GPU 是一块非常特殊的硬件，OpenGL 和 GPU 密切的工作以提高GPU的能力，并实现硬件加速渲染。对大多数人来说，OpenGL 看起来非常底层，但是当它在1992年第一次发布的时候(20多年前的事了)是第一个和图形硬件(GPU)交流的标准化方式，这是一个重大的飞跃，程序员不再需要为每个GPU重写他们的应用了。

不透明 VS 透明

当源纹理是完全不透明的时候，目标像素就等于源纹理。这可以省下 GPU 很大的工作量，这样只需简单的拷贝源纹理而不需要合成所有的像素值。但是没有方法能告诉 GPU 纹理上的像素是透明还是不透明的。只有当你作为一名开发者知道你放什么到 CALayer 上了。这也是为什么 CALayer 有一个叫做 opaque 的属性了。如果这个属性为 YES，GPU 将不会做任何合成，而是简单从这个层拷贝，不需要考虑它下方的任何东西(因为都被它遮挡住了)。这节省了 GPU 相当大的工作量。这也正是 Instruments 中 color blended layers 选项中所涉及的。(这在模拟器中的Debug菜单中也可用).它允许你看到哪一个 layers(纹理) 被标注为透明的，比如 GPU 正在为哪一个 layers 做合成。合成不透明的 layers 因为需要更少的数学计算而更廉价。

所以如果你知道你的 layer 是不透明的，最好确定设置它的 opaque 为 YES。如果你加载一个没有 alpha 通道的图片，并且将它显示在 UIImageView 上，这将会自动发生。但是要记住如果一个图片没有 alpha 通道和一个图片每个地方的 alpha 都是100%，这将会产生很大的不同。在后一种情况下，Core Animation 需要假定是否存在像素的 alpha 值不为100%。在 Finder 中，你可以使用 Get Info 并且检查 More Info 部分。它将告诉你这张图片是否拥有 alpha 通道。

像素对齐 VS 不重合在一起

到现在我们都在考虑像素完美重合在一起的 layers。当所有的像素是对齐的时候我们得到相对简单的计算公式。每当 GPU 需要计算出屏幕上一个像素是什么颜色的时候，它只需要考虑在这个像素之上的所有 layer 中对应的单个像素，并把这些像素合并到一起。或者，如果最顶层的纹理是不透明的(即图层树的最底层)，这时候 GPU 就可以简单的拷贝它的像素到屏幕上。

当一个 layer 上所有的像素和屏幕上的像素完美的对应整齐，那这个 layer 就是像素对齐的。主要有两个原因可能会造成不对齐。第一个便是滚动；当一个纹理上下滚动的时候，纹理的像素便不会和屏幕的像素排列对齐。另一个原因便是当纹理的起点不在一个像素的边界上。

在这两种情况下，GPU 需要再做额外的计算。它需要将源纹理上多个像素混合起来，生成一个用来合成的值。当所有的像素都是对齐的时候，GPU 只剩下很少的工作要做。

Core Animation 工具和模拟器有一个叫做 color misaligned images 的选项，当这些在你的 CALayer 实例中发生的时候，这个功能便可向你展示。

Masks

一个图层可以有一个和它相关联的 mask(蒙板)，mask 是一个拥有 alpha 值的位图，当像素要和它下面包含的像素合并之前都会把 mask 应用到图层的像素上去。当你要设置一个图层的圆角半径时，你可以有效的在图层上面设置一个 mask。但是也可以指定任意一个蒙板。比如，一个字母 A 形状的 mask。最终只有在 mask 中显示出来的(即图层中的部分)才会被渲染出来。

图片格式

当你在 iOS 或者 OS X 上处理图片时，他们大多数为 JPEG 和 PNG。让我们更进一步观察。

JPEG
每个人都知道 JPEG。他是相机的产物。它代表这照片如何存储在电脑上。甚至你嘛嘛都听说过 JPEG。

一个很好的理由，很多人都认为 JPEG 文件仅是另一种像素数据的格式，就像我们刚刚谈到的 RGB 像素布局那样。这样理解离真像真是差十万八千里了。

将 JPEG 数据转换成像素数据是一个非常复杂的过程，你通过一个周末的计划都不能完成，甚至是一个非常漫长的周末(原文的意思好像就是为了表达这个过程非常复杂，不过老外的比喻总让人拎不清)。对于每一个二维颜色，JPEG 使用一种基于离散余弦变换(简称 DCT 变换)的算法，将空间信息转变到频域.这个信息然后被量子化，排好序，并且用一种哈夫曼编码的变种来压缩。很多时候，首先数据会被从 RGB 转换到二维 YCbCr，当解码 JPEG 的时候，这一切都将变得可逆。

这也是为什么当你通过 JPEG 文件创建一个 UIImage 并且绘制到屏幕上时，将会有一个延时，因为 CPU 这时候忙于解压这个 JPEG。如果你需要为每一个 tableviewcell 解压 JPEG，那么你的滚动当然不会平滑(原来 tableviewcell 里面最要不要用 JPEG 的图片)。

那究竟为什么我们还要用 JPEG 呢？答案就是 JPEG 可以非常非常好的压缩图片。一个通过 iPhone5 拍摄的，未经压缩的图片占用接近 24M。但是通过默认压缩设置，你的照片通常只会在 2-3M 左右。JPEG 压缩这么好是因为它是失真的，它去除了人眼很难察觉的信息，并且这样做可以超出像 gzip 这样压缩算法的限制。但这仅仅在图片上有效的，因为 JPEG 依赖于图片上有很多人类不能察觉出的数据。如果你从一个基本显示文本的网页上截取一张图，JPEG 将不会这么高效。压缩效率将会变得低下，你甚至能看出来图片已经压缩变形了。

PNG
PNG读作”ping”。和 JPEG 相反，它的压缩对格式是无损的。当你将一张图片保存为 PNG，并且打开它(或解压)，所有的像素数据会和最初一模一样，因为这个限制，PNG 不能像 JPEG 一样压缩图片，但是对于像程序中的原图(如buttons，icons)，它工作的非常好。更重要的是，解码 PNG 数据比解码 JPEG 简单的多。

在现实世界中，事情从来没有那么简单，目前存在了大量不同的 PNG 格式。可以通过维基百科查看详情。但是简言之，PNG 支持压缩带或不带 alpha 通道的颜色像素(RGB)，这也是为什么它在程序原图中表现良好的另一个原因。

With –drawRect:

如果你的视图类实现了 -drawRect:，他们将像这样工作:
当你调用 -setNeedsDisplay，UIKit 将会在这个视图的图层上调用 -setNeedsDisplay。这为图层设置了一个标识，标记为 dirty(直译是脏的意思，想不出用什么词比较贴切,污染？)，但还显示原来的内容。它实际上没做任何工作，所以多次调用 -setNeedsDisplay并不会造成性能损失。

下面，当渲染系统准备好，它会调用视图图层的-display方法.此时，图层会装配它的后备存储。然后建立一个 Core Graphics 上下文(CGContextRef)，将后备存储对应内存中的数据恢复出来，绘图会进入对应的内存区域，并使用 CGContextRef 绘制。

当你使用 UIKit 的绘制方法，例如: UIRectFill() 或者 -[UIBezierPath fill] 代替你的 -drawRect: 方法，他们将会使用这个上下文。使用方法是，UIKit 将后备存储的 CGContextRef 推进他的 graphics context stack，也就是说，它会将那个上下文设置为当前的。因此 UIGraphicsGetCurrent() 将会返回那个对应的上下文。既然 UIKit 使用 UIGraphicsGetCurrent() 绘制方法，绘图将会进入到图层的后备存储。如果你想直接使用 Core Graphics 方法，你可以自己调用 UIGraphicsGetCurrent() 得到相同的上下文，并且将这个上下文传给 Core Graphics 方法。

从现在开始，图层的后备存储将会被不断的渲染到屏幕上。直到下次再次调用视图的 -setNeedsDisplay ，将会依次将图层的后备存储更新到视图上。

来自：http://objccn.io/issue-3-1/