duh*_*ime 3 frame-rate three.js
我正在使用Three.js WebGL场景，在缩小时注意到60 FPS，以便可以看到所有观测值（约20,000个三角形），但是在放大时，FPS却很低，因此只有一小部分三角形的子集在视图中。
我想找出造成这种差异的原因。我的直觉是相反的说法是正确的：我假设当用户在近，远剪切平面中缩放时，会从场景中删除许多三角形，这会增加FPS。我想弄清楚为什么在这种情况下这种直觉是错误的。
如何识别在three.js程序中使用的完整调用堆栈？理想情况下，我想确定所有函数/方法调用以及执行该函数所需的时间，以便我可以找出用户正在放大的着色器的哪一部分正在杀死FPS。
GPU具有一些基本的运算能力。这应该很明显。一种是每个顶点运行一次顶点着色器。另一个是每个像素/片段运行一次片段着色器。
几乎总是比顶点多一吨像素。单个1920x1080屏幕将近200万像素，但可以覆盖3个顶点三角形或4或6个顶点方形（2个三角形）。这意味着覆盖整个屏幕的顶点着色器运行了3到6次，而片段着色器运行了200万次！！！
向片段着色器发送过多的工作称为“填充绑定”。您将填充率最大化（用像素填充三角形），这就是您所看到的。在更糟糕的情况下，在我的2014 MacBook Pro上，在达到每秒60帧更新屏幕的填充率限制之前，我可能只能绘制6个左右的屏幕像素。
有多种解决方案。
第一个是z缓冲区。GPU将首先测试深度缓冲区，以查看是否需要运行片段着色器。如果深度测试失败，则GPU不需要运行片段着色器。因此，如果您对不透明的对象进行排序和绘制，则最靠近的对象首先到达最远的对象，然后，距离中的大多数对象在渲染其三角形的像素时将无法通过深度测试。请注意，这仅在您的片段着色器未写入gl_FragDepth且不使用discard关键字的情况下才可能。
这是一种“避免透支”的方法。过度绘制是指绘制多次的任何像素。如果您在远处绘制一个立方体，然后近距离绘制一个球体以使其覆盖该立方体，则对于为该立方体渲染的每个像素，球体像素都会“覆盖”该像素。那是浪费时间。
如果您的片段着色器确实很复杂，因此运行缓慢，则某些3D引擎将绘制“ Z缓冲区预传递”。他们将使用最简单的顶点和片段着色器绘制所有不透明的几何图形。顶点着色器仅需要位置。片段着色器仅发出一个恒定值。他们甚至会关闭对颜色缓冲区的绘制，gl.colorMask(false, false, false, false)或者如果硬件支持的话，甚至可能仅制作深度帧缓冲区。然后，他们使用它来填充深度缓冲区。完成后，他们将使用昂贵的着色器和深度测试将所有内容再次渲染为LEQUAL（或任何适用于其引擎的内容）。这样，每个像素将仅渲染一次。当然它不是免费的，它仍然需要GPU时间来尝试对三角形进行栅格化并测试每个像素，但是如果着色器很昂贵，它仍然比透支更快。
另一种方法是尝试找出哪些对象将被更近的对象遮挡，甚至不将其提交给GPU。有很多方法可以做到这一点，通常涉及边界球和边界框。一些潜在的可见集合技术也可以帮助遮挡剔除。您甚至可以要求GPU使用遮挡查询来计算其中的一部分，尽管仅在WebGL2中可用
查看是否被填充的最简单方法是使画布变细，例如2x1像素（或者只是将浏览器窗口的尺寸变小）。如果您的应用开始快速运行，则很可能已达到极限。如果它仍然运行缓慢，则可能是几何绑定（顶点着色器做过多的工作），也可能是CPU绑定（无论您在CPU上所做的任何工作都花了太长时间，无论是调用WebGL命令还是计算动画或碰撞）或物理学之类的东西）。
在您的情况下，您可能处于填充边界，因为您看到所有三角形都较小时，它运行很快（因为绘制的像素很少），而放大时看到很多三角形覆盖了屏幕，那么它运行得很慢（因为也是如此）许多像素）。
没有真正的“简单”解决方案。我真的只是取决于您要做什么。显然您使用的是three.js，我知道它可以对透明对象进行排序。我不知道它是否为不透明的对象排序。我认为列出的其他技术超出了three.js的范围，并且更多的取决于您的应用程序将事物带入或带出场景或将其可见性设置为false等。
注意：这是一个简单的演示，显示GPU可以处理的透支量很少。它只是绘制了一堆全屏四边形。默认情况下，它可能无法再绘制那么多图片，尤其是在全屏尺寸下，才无法再达到60fps。启用从前到后的排序功能，它将可以绘制更多内容，但仍然达到60fps。
还要注意，启用混合比禁用混合要慢。这应该很清楚，因为无需混合GPU即可写入像素。进行混合时，GPU必须首先读取目标像素，以便它可以进行混合，因此速度较慢。