Html 使用chrome://tracing

我试图提高延迟渲染器的FPS，所以我无意中发现了chrome://tracing （和）。我为我渲染的每一层添加了

console.time

和

console.timeEnd

。你可以在这里看到它们：

我的跟踪点是以

节点/…

开始的最顶端的项目，它们一起运行大约2ms。所有调用都在这两毫秒内完成。我目前的帧速率约为38帧，一帧约为28毫秒。现在，另一张用GPU处理缩小的图片：

你仍然可以看到那里的痕迹点，顶部的小条。奇怪的是，Chrome渲染两帧的速度非常快，然后在屏幕上运行这个神秘的

DoSwapBuffers

/

任务，停止渲染大约25毫秒，再加上与第二帧重叠的
MakeCurrent
任务，这需要15毫秒

在我看来，Chrome将所有WebGL任务推迟到以后，这使得不可能进行任何形式的分析。但那只是我的猜测。如何处理此问题以及如何评测我的WebGL代码？
由于GPU独立于主JS线程运行，只要呈现的数据没有直接反馈到JS上下文中，它就不会与JS活动同步。因此，发出任何WebGL命令都不会阻止JavaScript的运行，只有当GPU完成了JS发出的所有操作时，才会显示框架

因此，在此跟踪中不可能看到任何WebGL操作的实际计算时间

但是有一个简单的技巧：通过将一些依赖于渲染的数据拉回到JS世界来同步JS线程。最简单的方法是将每个中间纹理的一些像素渲染到3D画布上，并通过2D上下文
drawImage
方法将该画布渲染到2D画布上（确保通过
ctx.getImageData（）
访问该画布）。此方法非常慢，并且会增加一些时间，因为它还可以使所有WebGL绘制操作对分析/跟踪可见。
请注意，这也可能会在一定程度上扭曲结果，因为所有内容都将被迫按顺序计算，GPU驱动程序无法优化独立的绘制到操作以相互交错。
您是否有可能使用VSYNC？在这种情况下，这听起来几乎是正常的行为。实际帧的结束时间仅为VBLANK间隔恢复所需时间的一小部分，然后在交换链已满后，
SwapBuffers（…）
导致阻塞。@AndonM.Coleman Chrome的默认设置是使用VSYNC，但我在中禁用了它chrome://flags