使用来自 jni 的 openGL ES 时的 java glSurfaceView 与 Native-Activity

Question

我有一个 Android 项目，我在其中使用 JNI 在 gpu (openGL ES 2) 上进行渲染。

目前，我通过在 Java 中创建一个 glSurfaceView 来实现这一点，然后使用 onDrawFrame 调用我的 JNI 代码来执行 GLES 命令。虽然这可行，但渲染速度并不好。

我想知道如果我停止使用 java glSurfaceView 来处理上下文创建，而是尝试使用 Native-Activity 并在 cpp 中执行所有操作，是否可以获得更好的性能。

我认为这样我就不能再使用任何 java 代码了，所以我肯定会遇到其他麻烦，因为我的应用程序需要与一些 java android api 通信。

我可以想象 Native-Activity(我认为它仍然被一些 java 代码包裹)在底层使用相同的 glSurfaceView，所以不会有任何收获。

非常感谢有关此主题的任何信息。

我在 GPU 上的所有绘图都是使用 glDrawArray 完成的。也许这不是在 openGL ES 上运行的最快方式？

Answer 1

您需要分析瓶颈是软件还是 GPU。找出哪一侧是瓶颈后，您可以尝试优化那一侧。

glDrawElements 可以是对 glDrawArrays 的微小改进，因为顶点着色器可以为在网格中多次使用的每个顶点运行一次。但更重要的 GPU 端优化可以分段着色器、避免混合、确保深度测试正确防止多次重绘相同像素位置等。当然，如果您有复杂的几何图形，那么顶点处理也可能成为瓶颈。

快速估算某样东西的成本:

• 调用 java 代码一次 0.001-0.01ms (CPU)

• glDraw* 使用 VBO/IBO 0.01-0.1ms (CPU) 一次

• 廉价的顶点着色器 0.1-1ms (GPU)

• 昂贵的顶点着色器 1-10ms (GPU)

• 便宜的全屏 fragment 着色器 2-5ms (GPU)

• 昂贵的 fragment 着色器 30-100 毫秒(GPU)

• 整个屏幕混合 N 次将花费 N 倍的 fragment 着色器成本 (GPU)

免责声明:数字只是非常粗略的估计。您应该使用分析和基准来为您的用例找到真正的值(value)。