4

似乎是随机的（但在任何给定的程序运行期间通常是一致的），我的presentRenderBuffer调用非常慢。我把它追踪到了一个调用glFlush()，presentRenderBuffer所以现在我glFlush()在 presentRenderBuffer 之前调用。我放了一个计时器glFlush()，它会做两件事之一，似乎是随机的。

glFlush()任何一个

1) 始终需要 0.0003 秒

或者

2) 在大约 0.019 和 0.030 秒之间交替

最奇怪的是，这与绘图代码无关。即使我注释掉所有绘图代码以便它所做的只是调用glClear()，我仍然只是随机获得两个结果之一。

绘图方法由CADisplayLink具有以下设置的 an 调用：

dLink = [[UIScreen mainScreen] displayLinkWithTarget:viewController selector:@selector(drawFrame)];
dLink.frameInterval = 1;
[dLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];

我发现无法确定导致其中一个结果发生的原因。任何人都可以提供想法吗？

4

2 回答 2

3

通常，在 iOS OpenGL ES 调用上执行精确计时有点棘手，因为设备使用了基于 tile 的延迟渲染器。状态更改、绘图和其他操作可以推迟到呈现场景之前。

这通常会使类似的东西glFlush()或上下文-presentRenderBuffer:看起来非常慢，而实际上它只是导致在该点执行所有延迟渲染。

您注释掉所有绘图代码但glClear()不会受此影响的情况。您在交替示例中呈现的不同时间大致对应于 1/53 或 1/33 秒，这似乎表明它可能只是阻塞了足够长的时间以匹配屏幕刷新率。CADisplayLink 应该让您与屏幕刷新保持同步，但我可以看到您的绘图有时会略微偏离。

您是否在主线程上运行此测试？可能有一些东西导致主线程轻微阻塞，让你稍微偏离屏幕刷新时间。当我将渲染移到后台线程时，我发现这种振荡有所减少，但它仍然由 CADisplayLink 触发。当我这样做时，渲染速度也提高了，尤其是在多核 iPad 2 上。

最后，我认为glFlush()在 iOS 上使用 OpenGL ES 时不需要显式使用。您的 EAGLContext 的presentRenderbuffer:方法应该是将您的框架渲染到屏幕所需的全部内容。glFlush()我在这里的 OpenGL ES 应用程序中没有看到单个实例。在您的情况下，这可能是多余的。

于 2011-08-17T17:25:39.353 回答
1

我发现了我认为的问题。附加到 EAGLView 的视图控制器未按应有的方式设置为窗口的根视图控制器。相反，视图被手动添加为窗口的子视图。解决此问题后（以及其他一些相关修复），drawFrame 方法现在似乎与屏幕刷新完美同步。成功！

于 2011-08-22T08:06:18.850 回答