ios - 图形上下文的概念与文件句柄非常相似吗？ (在 iOS 和其他系统上)

Question

有时术语图形上下文有点抽象。它们实际上是系统资源，但它们是来自显卡的资源，就像文件句柄是来自硬盘驱动器或任何永久存储设备的系统资源一样？

正如文件句柄有一些关于文件句柄是只读还是读/写的状态，以及下一次读取操作的当前位置——这些状态，Graphics Context 有关于当前笔划颜色的状态，笔画宽度，或任何相关数据。 (更新:并且在写入模式下，我们可以转到 200MB 文件中的任意点并更改数据，就像我们拥有 Graphics Context 的 Canvas 并在其上绘制东西一样)

因此，Graphics Context 实际上是全局的、系统范围的资源。它们不是应用程序单例或任何东西的一部分，就像文件或文件句柄不是(不一定)应用程序单例的一部分一样。

如果没有强大的显卡(或者如果显卡已经耗尽资源)，那么操作系统可以使用位图使用低级图形例程模拟图形上下文，而不是让显卡处理它。

在 iOS 和大多数其他通用操作系统上，Graphics Context 实际上是这样工作的吗？

Answer 1

我认为最好不要从特定系统资源的角度考虑图形上下文。据我所知，图形上下文不再对应任何特定资源，就像任何类“对象”一样，当然除了内存。实际上，Graphics 上下文旨在为核心图形功能提供一个“ Canvas ”以供操作。事实上，Apple 并没有向我们提供有关图形上下文在内部如何工作的具体细节。但是我们确实知道几件事:

1. 图形上下文基本上是一种比其他任何东西都重要的“状态”。它包含一组特定绘图例程的描边/填充颜色、线条宽度等信息。

2. 它不在 GPU 上处理。相反，它在 CPU 上处理(完成所有绘制)并将生成的图像(某种形式的位图)“传递”到 GPU 以进行显示/动画(实际上它将图像直接渲染到 GPU 的缓冲区)。这就是“renderInContext”方法在新 iPad 3 中效果不佳的原因。renderInContext 首先为您提供图像，这涉及渲染和复制图像。如果您希望随后显示它，则必须将其传回 Core Graphics，然后再将图像写回。在 iPad 3 上，这涉及大量内存(取决于 View 的大小)并且很容易溢出缓冲区。

3. 提供给 UIView 的“drawRect”方法的图形上下文旨在提供尽可能高效的上下文。这就是为什么你不能在上下文之外的 View 中绘制任何东西，也不能为要绘制的 View 创建自己的上下文。实际的绘制是在运行循环中处理的，这就是为什么我们使用这个方法来标记一个需要绘制的UIView:[view setNeedsDisplay].

4. UIView 的图形上下文在主线程上绘制，是的，同样在 CPU 上处理。这确实意味着过于复杂的绘图会占用您的主要应用程序，但现在有了多核处理器，这并不是什么大问题。

5. 您可以创建图形上下文，但只能绘制到图像上。这与 UIView 上下文所做的完全相同，只是它是供您使用而不是绘制到屏幕或动画。从 iOS 4 开始，您可以在其他线程(除了主线程)中处理这些图像上下文。

   如果您想要进行 GPU 绘图，我相信唯一的方法是在您使用 iOS 时使用 OpenGL。如果您使用的是 MacOS，我认为您实际上可以使用 QuartzGL 在 GPU 上启用 Quartz(核心图形......相同的东西)绘图。但这可能不值得付出努力，请参阅这篇文章:Mac QuartzGL (2D drawing on the graphics card) performance

更新

正如您在下面的评论中所看到的，Apple 目前对 Quartz 绘图的安排可能是最好的，特别是因为 View 直接绘制到 GPU 缓冲区。有一种想法认为处理任何视觉应该在 GPU 上完成，但事实是，GPU 不是为矢量绘图而设计的。它们旨在处理大量变换、照明、纹理映射等。通过使用 CPU 处理矢量绘图并将其他一切留给 GPU，Apple 已适本地拆分了图形处理。此外，由于 Quartz 直接绘制到 GPU 的缓冲区(这避免了繁重的 memcpy)，因此您不会在 CPU 和 GPU 之间的数据传输中失去任何效率。