12

WebGL 很好而且是异步的，因为您可以发送一长串渲染命令而无需等待它们完成。但是，如果由于某种原因确实需要等待渲染完成，则必须与gl.finish(). gl.finish如果接受回调并立即返回肯定会更好吗？

问题：有什么方法可以可靠地模拟这个吗？

用例：我将大量顶点渲染到一个大的离屏画布，然后使用drawImage将这个大画布的部分复制到页面上的小画布。我实际上没有使用gl.finish()，但drawImage()似乎有相同的效果。在我的应用程序中，仅当用户执行操作（例如单击按钮）时才会触发重新渲染，并且可能需要数百毫秒。如果在渲染期间浏览器仍然响应允许滚动等，那就太好了。我特别在寻找 Chrome 解决方案，尽管在 Firefox 和 Safari 中也可以使用的东西会很好。

可能的（坏的）答案：您可以尝试估计渲染需要多长时间，然后设置一个以调用gl.finish(). 然而，可靠地对所有大小的顶点缓冲区和所有用户进行这种估计将非常棘手和不准确。

可能的（非）答案： requestAnimationFrame我正在寻找的东西......但它没有，是吗？

2018 年可能的答案：也许ImageBitmapAPI 解决了这个问题 - 请参阅MDN 文档。

4

1 回答 1

5

您已经部分回答了您的答案：drawImage()确实具有类似完成的行为，因为它强制所有未完成的绘图命令在读回图像数据之前完成。问题是，即使按照gl.finish()您的意愿进行操作，等待渲染完成，您仍然会像现在一样使用它。渲染完成时主线程将被阻塞，从而中断用户与页面交互的能力。

理想情况下，您在这种情况下想要的是某种回调，它指示一组绘制命令何时完成，而没有实际阻塞等待它们。不幸的是，不存在这样的回调（考虑到浏览器内部的工作方式，提供一个会非常困难！）

在您的情况下，一个不错的中间立场可能是对您认为图像何时准备就绪进行一些智能估计。例如，一旦你在调用requestAnimationFrame前 3 或 4 秒发送了你的绘图调用drawImage。如果您一直观察到它需要更长的时间（10 帧？）然后旋转更长时间。这将允许用户继续正常与页面交互，并且在绘制图像时不会产生延迟，因为内容已经完成渲染，或者因为您在渲染的中途执行同步步骤而产生的延迟要少得多。根据您网站的预期用途，非实时渲染甚至可能会在呈现前旋转整整一秒左右。

这当然不是一个完美的解决方案，我希望我有一个更好的答案给你。也许 WebGL 将来会获得查询这种状态的能力，因为它在像你这样的情况下很有价值，但现在这可能是你能做的最好的事情。

于 2013-08-26T20:47:00.870 回答