Question

看似随机（但在任何给定的程序运行期间通常都是一致的），我的presentRenderBuffer调用非常慢。我将其跟踪到glFlush() presentRenderBuffer拨打的电话，现在我在presentRenderBuffer之前调用glFlush()。我在glFlush()上放了一个计时器，它做了两件事之一，似乎是随机的。

glFlush()

1）始终需要0.0003秒

OR

2）在约0.019和0.030秒之间交替

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

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

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

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

Answer 1

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

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

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

您是否在主线程上运行此测试？可能会有一些东西导致主线程的轻微阻塞，使您略微偏离屏幕刷新时间。当我将渲染移动到后台线程时，我已经看到这种振荡的减少，但仍然由CADisplayLink触发。渲染速度也随着我的提高而增加，特别是在多核iPad 2上。

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

Answer 2

我发现了我认为的问题。附加到EAGLView的视图控制器未被设置为窗口的根视图控制器。而是将视图手动添加为窗口的子视图。当这个被修复时（以及其他一些相关的修复），drawFrame方法现在似乎与屏幕刷新完美同步。成功了！

iPhone OpenGL ES glFlush（）不一致慢

2 个答案: