javascript - readPixels 性能，是什么让它这么慢？

Question

当尝试使用大量数据(但屏幕上几乎没有数据)进行 HitTest 时，即使帧时间远低于 16.7 毫秒(总共 10 毫秒)，读取像素也非常慢

我正在开发一个在 webgl 中运行的 datavis 平台，但令我困惑的是为什么 readpixels 如此慢。我们正在使用颜色选择方法来 HitTest 被拖动的项目，以便它可以掉落到物体上等。尽管渲染(未读取)为 60fps，但上传到场景的数据越多，所需的时间就越长。它只拉出一个像素，因此它显然与它的阻塞方面相关，但为什么这会比帧时间长近 4 倍？

if (xPos >= 0 && yPos >= 0 && xPos < drawBufferWidth && yPos < drawBufferHeight) {
   gl.readPixels(xPos, yPos, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, lastCapturedColourMap);
}

我预计帧速率越高，读取像素的成本就越低，但这似乎是固定成本。有人可以启发我吗？我正在寻找任何可能更好地了解实际导致速度变慢的原因的人，或者寻找 webgl 中 2d 图形的任何其他替代 HitTest 方法的人

Answer 1

正如 mlkn 指出的那样，它很慢，因为 WebGL 是管道化的。为了安全起见，它在 Chrome 中采用双管道。

您从 JavaScript 发出 webgl 命令。该命令被复制到命令缓冲区。另一个进程，GPU 进程读取该命令，它验证您没有做坏事，然后调用一些相应的 GL 函数，该函数将命令写入驱动程序的命令缓冲区。另一个进程读取该命令。

在正常情况下，所有这些事情都是并行运行的。当您发出新命令时，GPU 进程会读取之前的命令并将其传递给 GL。当 GPU 进程发出命令时，GPU 和 GPU 驱动程序将停止处理之前的命令。

当您尝试读取时，所有并行运行的进程都必须停止，并且所有进程都必须等待所有命令处理完毕，以便它们可以读取像素(您发出的所有命令的结果)到目前为止)，然后将它们传回。然后它们都必须重新启动，但此时它们的所有命令列表都是空的，因此需要多个命令才能让它们再次并行执行某些操作。