我的 presentRenderBuffer
调用看似随机(但在任何给定程序运行期间通常是一致的)非常慢。我追踪到 presentRenderBuffer
对 glFlush()
的调用,所以现在我在 presentRenderBuffer 之前调用 glFlush()
。我在 glFlush()
上放置了一个计时器,它会做两件事中的一件,看起来是随机的。
glFlush()
或者
1) 始终花费 0.0003 秒
或
2) 在大约 0.019 和 0.030 秒之间交替
最奇怪的是,这与绘图代码无关。即使当我注释掉所有绘图代码以便它所做的只是调用 glClear()
时,我仍然只是随机获得两个结果之一。
绘图方法由具有以下设置的 CADisplayLink
调用:
dLink = [[UIScreen mainScreen] displayLinkWithTarget:viewController selector:@selector(drawFrame)];
dLink.frameInterval = 1;
[dLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
我发现无法确定导致其中一个结果发生的原因。有谁能出出主意吗?
最佳答案
在 iOS OpenGL ES 调用上执行精确计时通常有点棘手,因为设备使用了基于图 block 的延迟渲染器。状态更改、绘图和其他操作可以推迟到场景出现之前。
这通常会使 glFlush()
或上下文的 -presentRenderBuffer:
看起来非常慢,但实际上它只是导致所有延迟渲染在那一点执行。
您注释掉所有绘图代码但 glClear()
的情况不会受此影响。您在交替示例中出现的不同时间大致对应于 1/53 或 1/33 秒,这在我看来表明它可能只是阻塞了足够长的时间以匹配屏幕刷新率。 CADisplayLink 应该让您与屏幕刷新保持同步,但我可以看到您的绘图有时会略有偏离。
你是在主线程上运行这个测试吗?可能有一些东西导致主线程轻微阻塞,使您稍微偏离屏幕刷新时间。当我将渲染移动到后台线程时,我发现这种振荡有所减少,但它仍然由 CADisplayLink 触发。渲染速度也随着我这样做而提高,特别是在多核 iPad 2 上。
最后,我认为在 iOS 上使用 OpenGL ES 时不需要显式使用 glFlush()
。您的 EAGLContext 的 presentRenderbuffer:
方法应该是将帧呈现到屏幕所需的全部。我在这里的 OpenGL ES 应用程序中没有看到 glFlush()
的单个实例。在您的情况下,这可能是多余的。
关于iPhone OpenGL ES glFlush() 不一致地慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7090774/