ios - Metal/UIKit 与 .presentsWithTransaction 同步

Question

The Apple docs对于 CAMetalLayer 声明属性 presentsWithTransaction 是:

A Boolean value that determines whether the layer presents its content using a Core Animation transaction

因为我正在使用 UIKit 来驱动一些 Metal 动画(类似于 Apple 在这个 WWDC 2012 session 中为 OpenGL 建议的方法)，我假设这是启用它的正确时机。我有一个 Metal “背景” View ，上面覆盖了一些 UIKit 组件(也是动画)，所以这听起来非常像适用的用例:

By default [.presentsWithTransaction] is false: CAMetalLayer displays the output of a rendering pass to the display as quickly as possible and asynchronously to any Core Animation transactions. However, if your game or app combines Metal and Core Animation content, it's not guaranteed that your Metal content will arrive in the same frame as your Core Animation content. This could be an issue if, for example, your app draws UIKit content (such as labels with a target position and time) over the top of your CAMetalLayer and the two domains need to be synchronized.

当然，如果不启用该设置，滚动会出现抖动。在启用 presentsWithTransaction 的情况下，我取得了一些有限的成功，但我在启用设置的情况下尝试过的两条路线都不是完美的。

我尝试的第一种方法遵循 the docs 中的说明。对于 presentsWithTransaction。因此，在我的 MTKViewDelegate 中，我有以下方法:

func draw(in view: MTKView) {
    guard
        let commandBuffer = commandQueue.makeCommandBuffer(),
        let drawable = view.currentDrawable
    else { return }

    updateState(device: device, library: library) // update positions, etc.
    render(with: commandBuffer, in: view) // drawing code

    commandBuffer.commit()
    commandBuffer.waitUntilScheduled()
    drawable.present()
}

这在大多数情况下都可以正常工作——但完全关闭设置也是如此。它有在某些点不同步的趋势，例如通过 UIScrollView 导致滚动动画的特征颤抖。 presentsWithTransaction 的整个想法就是为了避免这种情况，所以也许我在这里做错了什么。

第二种方法在命令缓冲区上使用addScheduledHandler:

func draw(in view: MTKView) {
    guard
        let commandBuffer = commandQueue.makeCommandBuffer(),
        let drawable = view.currentDrawable
    else { return }

    updateState(device: device, library: library) // update positions, etc.
    render(with: commandBuffer, in: view) // drawing code

    commandBuffer.addScheduledHandler { _ in
        DispatchQueue.main.async { drawable.present() }
    }
    commandBuffer.commit()
}

此方法似乎保持同步，但会导致一些可怕的 CPU 挂起(2 秒或更长时间)，尤其是当应用程序在后台运行后变得活跃时。

有什么方法可以两全其美吗？

编辑:2018 年 12 月 9 日:虽然上面描述的第一种方法似乎是优先的，但如果主线程上的 CPU 使用率出现峰值，它仍然会导致频繁的去同步——这在大多数情况下是不可避免的。

当绘制循环变得缺乏可绘制对象时，您可以判断这种情况何时发生。这会导致链式 react ，这意味着下一帧的可绘制对象也会延迟。在 Metal Instruments 面板中，这会导致出现一系列“线程阻塞等待下一个可绘制对象”警告。

在上面的设计中，由于 Metal 被阻塞等待可绘制 - 主线程也是如此。现在触摸事件变得延迟，导致平移手势出现独特的断断续续模式——即使应用程序理论上仍以完整的 60fps 运行，阻塞似乎会影响报告触摸事件的节奏——导致抖动效果。

随后的 CPU 峰值可能会使事情恢复正常，应用程序将开始正常运行。

编辑:2018 年 12 月 10 日:这是一个演示该问题的小示例项目。创建一个新的 Xcode 项目复制并粘贴两个 swift 文件的内容(为 Metal 着色器文件添加一个新文件)并在设备上运行:

https://gist.github.com/tcldr/ee7640ccd97e5d8810af4c34cf960284

Answer 1

编辑 2018 年 12 月 9 日:我正在从这个答案中删除已接受的答案指定，因为这个错误似乎仍然存在。虽然以下内容降低了错误发生的可能性，但它仍然确实发生了。原始问题中的更多信息。

原始答案:这似乎对我有用:

func draw(in view: MTKView) {

    updateState()  // update positions, etc.

    guard let commandBuffer = commandQueue.makeCommandBuffer() else { return }

    autoreleasepool { render(with: commandBuffer, in: view) } // drawing code

    commandBuffer.commit()
    commandBuffer.waitUntilScheduled()
    view.currentDrawable?.present()
}

MTKView 上的

.presentsWithTransaction 也设置为 true

我的想法是等到最后一刻才调用 currentDrawable，这在文档的某个地方被建议，但我现在不记得在哪里了。至少，我认为它应该在 .waitUntilScheduled() 之后调用。