在我的应用程序中，我使用LINE_STRIP标志一次调用WebGL的drawarrays来绘制大约800万个顶点。我实际上并不想要一条长线，我想要大约200k短线，所以我用额外的顶点限制所有短线，并告诉顶点着色器将线帽“推”到负z以创建不可见的桥。渲染是准静态的（用户可以点击触发重新渲染的各种事物），因此它不一定非常快，但我真的希望在现代计算机上花费不到200毫秒。
在我的笔记本电脑上[更新：运行Win7，使用一些Intel i7s作为其CPU和集成的HD Graphics 4000 for GPU]我在Chrome中获得了大约100ms，这很好。奇怪的是，Firefox大约1-2秒。在我的三星Chromebook 550上，我得到600毫秒到2秒的任何东西，通常它会快速启动，然后后续渲染会变慢但速度也会变快。
问题：
备注：
对于Chromebook重复渲染测试，渲染之间唯一发生的事情是将制服更改为在调色板之间切换（实现为纹理）。 Chrome开发工具似乎认为在测试期间页面的内存使用量没有任何重大变化。
我正在使用gl.finish和console.time查看渲染时间。
除了在调试过程中，我渲染到一个孤立的画布，然后使用drawImage（以webgl画布作为第一个参数）将结果的各个部分复制到页面 UPDATE：上的各种小画布上）。这可能需要花费一些时间，但无论有没有复制操作，并且有或没有附加到页面主体的webgl画布（并且可见），上面报告的数字似乎没有太大变化。
更新：笔记本电脑一次性渲染的顶点数量有限制，但限制似乎会随时波动，如果超过限制则没有呈现任何东西。这个数字大约是800万大关，但有时它很乐意超过1100万。我现在已经将其设置为每次批量200万。有趣的是，这似乎使我的Chromebook变得更快，但我无法确定它是如此不一致。
更新：我已禁用DEPTH_TEST和BLEND，因为我不需要它们。我不相信它有任何区别。
更新：我尝试使用POINTS而不是LINES进行渲染。在我的Chromebook上，它似乎需要大约1秒，0点大小（即什么都不渲染），然后大约1.5-2秒，因为我将点大小增加到1,2和5。
更新：保持z = 0平面上的所有内容似乎不会改变速度，也许它会变慢一点（我希望它有很多更多像素通过片段着色器，尽管片段着色器只是将变化的直线汇集到gl_FragColor中。
答案 0 :(得分：0)
虽然通常（好的）建议是在每次绘制调用中尽可能多地渲染，但是一些（我知道至少一个）GPU在处理顶点数据时使用了内部缓冲区。超过这些缓冲区的容量可能会使您的性能下降。减少顶点批次的大小，直到开始看到批量太小的性能下降。