macos - 是否需要在主线程上绘制到 MTKView 或 CAMetalLayer？

Question

众所周知，更新 AppKit 中的用户界面或 UIKit需要在主线程上进行。在展示 drawable 时，Metal 是否有相同的要求？ ?

在一个层托管 NSView我一直在玩，我注意到我可以调用[CAMetalLayer nextDrawable]来自 dispatch_queue那不是main_queue .然后我可以像往常一样更新该drawable的纹理并呈现它。

这似乎工作正常，但我觉得这相当可疑。除非我忽略了文档中的某些内容，否则我找不到任何提及 Metal 的主线程要求(支持或反对)。

(我正在 macOS 10.13 上进行测试，但我认为 iOS 的主线程要求也相同......？)

Answer 1

在后台线程上绘制是安全的。 docs for -nextDrawable 说:

Calling this method blocks the current CPU thread until a new drawable is available.

(强调。)如果它只能在主线程上调用，那可能不会那么概括。此外，Apple 的一般建议是避免阻塞主线程，所以你会认为他们会在这里以某种方式指出这个事实，例如建议你不要调用它，除非你很确定它不会阻塞。

关于如何使用drawable(而不是获取)，注意一个典型的用例是调用命令缓冲区的 -presentDrawable:。方法。该方法便于添加调度的处理程序 block (如通过 -addScheduledHandler: )，然后调用 -present在可绘制对象上。未指定将调用处理程序 block 的线程或队列，这表明 -present对drawable的调用将发生在主线程上。

即使在那之后，drawable 在屏幕上的实际呈现在对 -present 的调用中也不是同步的。 .可绘制对象等待直到渲染或写入其纹理的任何命令完成，然后才呈现到屏幕上。没有具体说明如何实现这种异步性，但它进一步表明，使用什么线程并不重要 -present被调用。

Metal Programming Guide 中有一些关于多线程的讨论。 ，尽管它并不像人们希望的那样直接。详见 the section on Multiple Threads, Command Buffers, and Command Encoders .请注意，这里讨论了由后台线程填充的命令缓冲区，并且没有关于使用可绘制对象的具体警告。同样，这是一种缺乏证据的论点，但我认为这很清楚。他们确实呼吁一次只能有一个线程对给定的命令缓冲区进行操作，因此他们正在考虑线程安全问题。