glBufferData 在 Cocos2d-x 3.3 中使用大纹理（精灵表）非常慢

Question

我正在使用 Cocos2d-x 将我的 PC 游戏移植到 Android。 对于精灵部分，我想优化渲染过程，所以我决定动态创建包含所有精灵帧的精灵表。

不幸的是，这使得渲染过程比使用仅包含当前精灵帧的小纹理慢了大约 10-15 倍（在移动设备上，在 Windows 上一切都运行顺利）。

我最初认为这可能与工作表之间的切换（如 4096*4096 之类的大纹理）有关，因为渲染过程会显示一张表中的一个精灵，然后显示另一张表中的另一个精灵，依此类推……做了很多巨大的纹理之间的切换。 所以我在将精灵帧“放入”精灵表之前对精灵进行了排序，我可以确认这些开关现在不存在了。

经过长时间的调查、分析、测试等……我终于发现一个 Open GL 函数需要所有时间：

glBufferData(GL_ARRAY_BUFFER, sizeof(_quadVerts[0]) * _numberQuads * 4, _quadVerts, GL_DYNAMIC_DRAW);

如果我使用大纹理，调用此函数需要很长时间（分析器表示每次调用超过 20 毫秒），如果我使用小纹理则非常快（大约 2 毫秒）。

我不太了解 Open GL，我在使用它是因为 Cocos2d-x 使用它，而且我不放心尝试调试/优化引擎，因为我真的认为它们比我好得多那:)

我可能误解了一些东西，几天以来我一直坚持这个问题，我不知道我现在能做什么。

有什么线索吗？

注意：我说的是 glBufferData，但我对 glBindFramebuffer 也有同样的问题，大纹理非常慢。我认为这是同一个主题。

谢谢

Answer 1

这通常是一个昂贵的调用，因为 glBufferData 涉及 CPU 到 GPU 的传输。 但 Renderer::drawBatchedQuads 背后的逻辑是刷新已缓冲在临时数组中的四边形。您必须渲染的四边形越多，必须传输的数据就越多。 由于四边形属性（位置、纹理、颜色）可能会改变每一帧，因此每帧都需要 CPU 到 GPU 的传输，正如标志 GL_DYNAMIC_DRAW 所暗示的那样。

根据规格：

GL_DYNAMIC_DRAW：数据存储内容会被反复修改，多次作为GL绘图命令的来源。

glBufferData 有可能的替代品，例如可以用于比较的 glMapBuffer 或 glBufferSubData。