google-chrome - 为什么 WebGL 渲染速度如此不一致？

Question

在我的应用程序中，我使用 LINE_STRIP 标志通过一次调用 WebGL 的 drawarray 绘制了大约 800 万个顶点。我实际上并不想要一条长线，我想要大约 200k 条短线，所以我用额外的顶点覆盖所有短线，并告诉顶点着色器将线帽“推”到负 z 以创建不可见的桥。渲染是准静态的(用户可以单击触发重新渲染的各种内容)，因此它不必非常快，但我真的希望在现代计算机上花费不到 200 毫秒。

在我的笔记本电脑上 [更新:它使用几个 Intel i7 作为 CPU 和一个集成的 HD Graphics 4000 作为 GPU 运行 Win7] 我在 Chrome 中得到大约 100 毫秒，这很好。奇怪的是，Firefox 大约需要 1-2 秒。在我的三星 Chromebook 550 上，我得到从 600 毫秒到 2 秒的任何时间，通常它开始很快，然后随后的渲染变慢，但它也可以变快。

问题:

什么可能导致我的 Chromebook 渲染速度发生变化？

为什么 Firefox 在我的笔记本电脑上比 Chrome 慢这么多？

是否值得花费很多时间来让它运行得更快(即我能期待很多改进)吗？有小费吗？

备注:

对于 Chromebook 重复渲染测试，渲染之间唯一发生的事情是统一更改为在调色板之间切换(作为纹理实现)。 Chrome 开发工具似乎认为在测试期间页面的内存使用情况没有任何重大变化。

我正在使用 gl.finish 和 console.time 来查看渲染需要多长时间。

除了在调试期间，我渲染到一个孤立的 Canvas ，然后将结果的部分复制到页面 UPDATE 上的各种小 Canvas :使用 drawImage(使用 webgl Canvas 作为第一个参数)。这可能确实需要一些时间，但是无论是否进行复制操作以及是否附加到页面主体(和可见)的 webgl Canvas ，上面报告的数字似乎都没有太大变化。

更新:我的笔记本电脑一次渲染的顶点数量是有限制的，但这个限制似乎时时刻刻都在波动，如果你超过了这个限制，那么它就不会渲染任何东西。这个数字大约是 800 万大关，但有时超过 1100 万也很高兴。我现在将它设置为一次批处理 200 万。有趣的是，这似乎让我的 Chromebook 运行得更快，但我不能确定，因为它是如此不一致。

更新:我已经禁用了 DEPTH_TEST 和 BLEND，因为我不需要它们。我不相信这有什么不同。

更新:我尝试使用 POINTS 而不是 LINES 进行渲染。在我的 Chromebook 上，0 点大小(即不渲染任何内容)似乎需要大约 1 秒，然后当我将点大小增加到 1,2 和 5 时大约需要 1.5-2 秒。

更新:将所有内容保持在 z=0 平面上似乎并没有太大改变速度，也许它会变慢一点(我希望有更多的像素可以通过片段着色器，尽管片段着色器只是将不同的直接汇集到 gl_FragColor 中)。

Answer 1

尽管通常的(好的)建议是在每次绘制调用中尽可能多地渲染，但一些(至少我知道的)GPU 在处理顶点数据时使用了内部缓冲区。超过这些缓冲区的容量会使您的性能下降。减少顶点批次的大小，直到您开始看到由于批次太小而导致性能下降。