Opengl es 基于OpenGL的动画/可缩放2D UI渲染优化策略

我已经为我的应用程序的UI构建了一个基于场景图的渲染系统（如果你好奇的话）。该应用程序的UI是程序化的，而且很多都是动画的。预渲染图像很少

目前，它在mipmapped纹理中缓存不变的可绘制组。我使用mipmap是因为UI是可缩放的。总的来说，这是一个巨大的性能胜利，但也有几个缺点：

构建mipmap（通过glGenerateMipmap）需要时间，当UI的一部分从动画变为静态时，会降低帧速率

纹理缓存几何体与非缓存几何体之间的视觉差异，导致轻微闪烁。（可能可以通过更巧妙地使用路径渲染代码来解决这个问题，但这似乎很难做到）

所有纹理的内存使用情况（我可以转储屏幕外纹理，但这会加剧问题1）

我想到了两种替代方法：

将静态路径合并为更大的路径，而不是纹理缓存。我的路径已经基于VBO/VAO，但这可以减少GL调用的数量。（当关闭纹理缓存时，我的性能主要受CPU限制）。在内存使用方面取得了巨大的成功。这种方法的主要问题是：使路径渲染着色器复杂化（因为它必须在一次调用glDrawArrays中处理具有不同属性的路径），不处理其他基本体（如文本）的缓存，并且GPU的负担比简单渲染纹理更重

仍然使用纹理，但避免mip贴图。随着UI的缩放，可以调整纹理的大小（尽管这可能不得不推迟，因为在缩放期间重新呈现整个UI的成本太高）。删除屏幕外几何体的纹理。当然，缺点是UI缩放过程中纹理放大/缩小效果不佳

更新

我试过了。调整纹理的大小相当慢，因此我防止UI在缩放期间调整纹理的大小。这项功能相当不错，但从较小的地方开始缩放时，放大率看起来很糟糕：

请注意，有些模块没有纹理缓存，因为它们被标记为动画

更新2

我开始研究方法1，所以我停用了纹理缓存

虽然我受CPU限制，但实际上我所有的GPU端负载都来自路径抗锯齿片段着色器。以下是它的性能：

然后，关掉它：

因此，进一步优化这将是GPU方面的一大胜利。我尝试放弃它并使用4x超级采样，但这看起来像垃圾，提醒我为什么我花了大量时间在路径渲染着色器上。

方法（1）是一个巨大的胜利。它的性能与纹理缓存基本相同，但没有任何视觉瑕疵或大量内存使用

---

路径渲染是否基于绘制GL\U线？缩小时是否简化了几何体？如中所示，对象确实具有LOD？感谢您的回复！所有路径均使用GL_三角形_带。我没有任何详细资料。作为测试，我尝试减少路径细分细节，确实在一定程度上减少了GPU渲染时间，但没有纹理缓存，我的CPU受到限制。因此，一旦我将CPU端负担降低了一点，动态LOD将是一个很好的实现方法：-）您的CPU端负担到底是什么？它正在变换这些顶点吗？或者只是将它们按帧发送到GPU？顶点存储在VBO中（在其可绘制的本地坐标中），并在顶点着色器中进行变换。我认为我的CPU方面的负担很大程度上是由于OpenGL调用的数量（上图中每帧780个调用glDrawArrays），但我可能做了一些错误的事情，需要CPU等待GPU（仍在调查）。再次感谢你的帮助！您是针对一个VBO发出多个调用，还是有多个VBO？在完成glDrawArrays调用序列之前，您是否在任何地方调用glFlush/glFinish？