iPhone OpenGL ES glFlush() 不一致地慢

标签 iphone ios performance opengl-es cadisplaylink

我的 presentRenderBuffer 调用看似随机(但在任何给定程序运行期间通常是一致的)非常慢。我追踪到 presentRenderBufferglFlush() 的调用,所以现在我在 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/

相关文章:

ios - numberOfRowsInSection 在 Alamofire 连接之前被调用

javascript - ionic ios 应用程序卡在初始屏幕上 - 在模拟器中工作,而不是在 iphone 5s 设备上

iOS UIButton 事件,当它的框架在 superview 的负位置时

performance - 开发插件时使用标准 Confluence 缓存

c# - 为什么将许多小字节数组写入文件比写入一个大数组更快?

iphone - iOS/iPhone 上的正常运行时间卡住

javascript - 如何从 Javascript 调用原生 Iphone/Android 函数?

ios - iPad 应用程序左右两侧的空格

ios - 在 UICollectionViewController 的搜索栏中隐藏键盘

java - Android 上常见的性能缺陷?