我同意@timday 的观点，即您应该将调查偏向“真实”的事情，并且正如您在评论中所建议的那样，您可能希望这个故事是关于在基于桌面或基于浏览器的应用程序之间做出决定的。
这正是我现在正在做的事情。我的客户端有一个当前在 Windows 桌面上运行的可视化应用程序。他们的典型场景有 500,000 个三角形、大量纹理和透明度。目前，他们的用户不愿意安装查看器——他们倾向于在系统管理员控制其计算机上安装的内容的公司环境中工作。一些用户更愿意在他们的 iPad 上运行可视化，而查看器无论如何都不会运行。所以我的客户想知道 WebGL 是否会解决他们的平台问题——别说没有浏览器正式支持 WebGL，而且 IE 和 iPad 都没有宣布任何形式的支持。
请记住，您所做的任何基准测试都相对没有意义，因为您正在测量一个移动的目标。浏览器制造商正在努力实现 WebGL，并且他们经常更新他们的 beta 版本。他们不仅致力于以一致的方式实现 WebGL，而且还必须担心浏览器安全问题和整体管道流程。 该视频讨论了一些问题（并让您了解要研究的内容）。同样，性能可能会因您的操作系统和图形硬件而异。
正如您所指出的，一旦 WebGL 在图形硬件中运行，它的运行速度应该与桌面应用程序一样快。您的基准测试应该尝试确认这一点，然后您应该尝试测量由于在浏览器中而导致性能损失的地方。我的感觉是 Javascript 本身并不是瓶颈，只是因为没有那么多 Javascript 可以执行（而且现在它非常快）。但是，如上述视频末尾所述，在 Javascript-C++ 绑定、请求验证、流控制等方面可能会出现效率低下的情况。另一方面，浏览器制造商（至少是谷歌）正在努力解决这些问题。
我注意到的一件事不是帧速率/性能问题（在我当前的测试中，我可以以 30 fps 的速度渲染 500,000 个纹理三角形），但帧速率似乎不是很一致，而且帧似乎被丢弃时。我怀疑，但不知道这是否与相对简单的setInterval()方式或在 Javascript 中运行动画有关。（Mozilla 的 mozRequestAnimationFrame 可能是一种更好的处理方式）。
尽管我不知道上述任何内容对您的论文有多大帮助，但在我看来，您的主题很丰富，您应该做的不仅仅是炮制简单的基准测试。也许你应该从一些基准开始，比较浏览器和桌面的性能，然后尝试检查最佳实践，不仅可以在浏览器和桌面之间做出决定，还可以用于编写 WebGL 应用程序。
那里也有很多 WebGL 框架。我尝试了几个，印象非常深刻——可以从他们身上学到很多东西。根据您的兴趣和论文要求，您可能也有兴趣对这些进行基准测试。
不管你走哪条路，我怀疑会有一大群潜在的 WebGL 采用者会渴望你将要研究的那种信息。