看似随机(但在任何给定程序运行期间通常都是一致的)，我的presentRenderBuffer调用非常慢。我将其跟踪到对glFlush()进行的presentRenderBuffer的调用，因此现在我在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调用上执行准确的计时有些棘手。可以将状态更改，绘图和其他操作推迟到呈现场景之前。
这通常会使glFlush()或上下文的-presentRenderBuffer:看起来很慢，而实际上这只是导致所有延迟渲染都在该点执行。
您注释掉所有工程图代码但glClear()的情况将不受此影响。您在交替示例中出现的时序变化大约对应于1/53或1/33秒，这似乎向我表明，它可能只是阻塞了足够长的时间以匹配屏幕刷新率。 CADisplayLink应该使您与屏幕刷新保持同步，但是我有时会看到您的图形略微偏离。
您是否正在主线程上运行此测试？可能是由于某种原因导致主线程的轻微阻塞，使您稍微偏离了屏幕刷新时间。当我将渲染移至后台线程时，我已经看到这种振荡的减少，但是仍然由CADisplayLink触发。这样做时，渲染速度也有所提高，尤其是在多核iPad 2上。
最后，我认为在iOS上使用OpenGL ES时，您不需要显式使用glFlush()。您的EAGLContext的presentRenderbuffer:方法应该是将框架呈现到屏幕所需的全部方法。我的OpenGL ES应用程序中没有看到glFlush()的单个实例。在您的情况下，这可能是多余的。