我正在使用Cocos2d-x将我的PC游戏移植到Android。 对于精灵部分，我想优化渲染过程，所以我决定动态创建包含所有精灵帧的sprites表。
不幸的是，这使得渲染过程比使用仅包含当前精灵的帧的小纹理慢大约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有同样的问题，对于大纹理来说非常慢。我认为这是完全相同的主题。
由于
答案 0 :(得分：0)
这通常是一个代价高昂的调用，因为glBufferData涉及CPU到GPU的传输。 但Renderer :: drawBatchedQuads背后的逻辑是刷新已在临时数组中缓冲的四边形。您必须渲染的四边形越多，传输的数据就越多。 由于四边形属性（位置，纹理，颜色）可能会更改每个帧，因此每个帧都需要CPU到GPU传输，如GL_DYNAMIC_DRAW标志所示。
根据规格：
GL_DYNAMIC_DRAW：数据存储内容将被重复修改并多次用作GL绘图命令的来源。
glBufferData可能有替代方案，例如glMapBuffer或glBufferSubData可用于比较。