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

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

就像文件句柄具有某些状态有关文件句柄是只读还是读/写，以及下一次读取操作的当前位置(状态)一样，图形上下文也具有有关当前笔触颜色，笔触宽度，或任何相关数据。 (更新:，在写入模式下，我们可以转到200MB文件中的任意点并更改数据，就像我们拥有Graphics Context的画布并在其上方绘制内容一样)

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

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

这是图形上下文在iOS和一般大多数其他常见OS上实际工作的方式吗？

最佳答案

我认为最好不要以特定的系统资源来考虑Graphics Context。据我所知，除了内存之外，图形上下文不再像任何类“对象”那样对应于任何特定资源。实际上，Graphics上下文旨在为核心图形功能提供“画布”以供操作。事实是，Apple没有向我们提供图形上下文内部工作方式的具体细节。但是，我们对此有几件事了解:

图形上下文基本上是一个“状态”，而不是其他任何东西。它包含一组特定的绘图例程的信息，例如笔画/填充颜色，线宽等。

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

提供给UIView的'drawRect'方法的图形上下文旨在提供尽可能高效的上下文。这就是为什么您不能在上下文外部的视图中绘制任何内容，也不能为视图插入创建自己的上下文的原因。实际的绘制在运行循环中处理，这就是为什么我们使用此方法来标记a需要绘制的UIView:[view setNeedsDisplay]。

UIView的图形上下文在主线程上绘制，是的，再次在CPU上进行处理。这的确意味着过于复杂的工程图可能会占用您的主要应用程序，但如今使用多核处理器的日子已经不那么多了。

您可以创建图形上下文，但是只能绘制以绘制图像。这与UIView上下文完全一样，只是它是供您使用的，而不是绘制到屏幕上或进行动画处理。从iOS 4开始，您可以在其他线程(主线程之外)中处理这些图像上下文。
如果您要进行GPU绘图，我相信唯一的方法就是在使用iOS的情况下使用OpenGL。如果您使用的是MacOS，我认为您实际上可以使用QuartzGL在GPU上启用Quartz(核心图形...同样的东西)绘图。但这可能不值得付出努力，请参阅本文:Mac QuartzGL (2D drawing on the graphics card) performance

更新
正如您在下面的评论中看到的那样，Apple当前用于Quartz绘制的安排可能是最好的，尤其是因为视图是直接绘制到GPU缓冲区的。有一种想法认为应该在GPU上进行任何视觉处理，但事实是，GPU并不是为矢量图设计的。它们旨在处理大量的变换，光照，纹理贴图等。通过使用CPU处理矢量绘图并将其他所有东西留给GPU，Apple适当地分割了图形处理。此外，由于Quartz直接吸引到GPU的缓冲区(这避免了繁重的内存工作)，因此您在CPU和GPU之间的数据传输上不会失去任何效率。

关于ios - 图形上下文的概念与文件句柄非常相似吗？ (在iOS和其他系统上)，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/10775738/