2015 年 7 月，我们发布了我们的 游戏技术路线图，并一直在努力解决开发者提出的痛点。

游戏是网页体验的重要组成部分。Mozilla 和其他浏览器供应商一直在努力寻找开发者可以迁移到的替代路径。随着插件的逐步退出（Firefox 52）以及许多浏览器计划在 2017-2018 年期间将 Flash 设置为点击播放，我们正在努力完善替代方案，确保其可行。许多有助于改进平台的新功能将在 Firefox 的未来几个版本中发布，我们也看到其他浏览器正在走类似的道路。

我们一直在与其他浏览器、工具制造商和游戏开发者紧密合作，进行大规模测试，并促进关键技术在所有主要浏览器中的普遍可用性。我们见证了 Facebook 上热门游戏取得成功，例如来自 King 的 泡泡女巫 3 传奇 和 糖果粉碎传奇，以及来自 Nordeus 的 Top Eleven。我们还有很多工作要做才能充分发挥平台的潜力，但今天我们想提供关于我们一直在做的事情以及您将在不久的将来在浏览器中看到的内容的最新情况。无论您使用的是编译代码库和/或 JavaScript，这里都有一些适合每个人的内容！

我们听到的反馈

当我们接触到游戏开发者、发行商和浏览器制造商时，我们听到了许多共同的担忧和需求

• 开发者希望改善用户体验。他们告诉我们，他们希望看到代码大小减少、编译和加载时间加快、内存使用减少以及性能提升，以便用户更容易参与其中。
  • WebAssembly 是解决所有这些问题的重大进步。
  • 我们最近 宣布 四大浏览器已就标准的稳定初始版本达成共识，使所有浏览器都能够开始发布 WebAssembly。
  • Mozilla 旨在在 2017 年 3 月发布 WebAssembly，作为 asm.js 的继任者，它将在 Firefox 52 中发布。
• 开发者希望能够覆盖尽可能多的用户，并且希望看到更多用户能够运行 WebGL 内容。
  • 有针对性的努力已经将非 Windows XP 机器上的桌面 WebGL 成功率从 80% 提升到了 99%。我们也看到其他浏览器出现了类似的趋势。此外，遥测数据显示，桌面 WebGL 的可用性与 Firefox 上的 Flash 相匹配。
  • 开发者希望在 WebGL 2 中使用 OpenGL ES3 功能，包括新的纹理格式，以及对浮点纹理过滤、渲染到多个渲染目标和 MSAA 多重采样的支持。
  • WebGL 2 支持 OpenGL ES3 功能。WebGL 2 于 2017 年 1 月在 Firefox 51 中发布，其他浏览器 也在紧随其后。
• 开发者要求在 32 位系统上分配更大数量的地址空间，以便运行更大、更复杂的应用程序，从而获得更大的灵活性。
  • 32 位内存不足（OOM）问题通常是由浏览器进程由于地址空间碎片而无法分配大块内存引起的。
  • Firefox 旨在在 2017 年 4 月的 Firefox 53 中发布 32 位 OOM 解决方案。
    我们在 Firefox 的 64 位版本中没有类似的挑战。
• 开发者希望获得更多关于 Firefox 用户在网络上使用的硬件的信息，以便为他们的开发决策提供参考。
  • 我们去年年底发布了 Firefox 硬件报告 的 1.0 版本。

详情

标准化和发布 WebAssembly

WebAssembly 是一种新兴的标准，其目标是定义一种安全、可移植、尺寸和加载时间效率高的二进制编译器目标，它提供了接近原生性能的性能——网络的虚拟 CPU。WebAssembly 正在 W3C 社区组 (CG) 中开发，其 成员 包括 Mozilla、Microsoft、Google 和 Apple。

WebAssembly 可以被认为是 asm.js 的继任者，Mozilla 倡导的项目，旨在突破现有 JavaScript 语言约束下的性能极限。尽管 asm.js 现在在所有浏览器中都提供了 令人印象深刻的性能，但作为一项新的标准，WebAssembly 消除了偶然的约束，使引擎能够越来越接近原生性能（同时保持与 JavaScript 相同的安全模型）。Firefox 中的初步测量结果 显示，平均而言，WebAssembly 使现实的 C/C++ 工作负载在 1.25 倍的原生速度内运行，低于 asm.js 的 1.38 倍——提高了 9%！随着整个管道的继续工作，预计将进一步提高速度。对于利用 WebAssembly 新功能（如 64 位整数算术）的合成工作负载，已观察到显著的 8 倍加速。

我们最近 宣布 WebAssembly 社区组已就标准的初始版本达成共识。可互操作的实现已 加入预发布 Firefox 和 Chrome 通道，并正在 Chakra 和 JavaScriptCore 中开发。Mozilla 旨在在 2017 年 3 月发布 WebAssembly，作为 asm.js 的继任者，它将在 Firefox 52 中发布。

提高 WebGL 成功率

我们已经能够识别并解决影响 Firefox 上 WebGL 可用性的问题。特别是，Firefox 遥测数据显示，我们已将所有机器上的 WebGL 可用性故障率从 Firefox 47 中的 20% 以上降低到 Firefox 50 中的 8% 以下。有针对性的努力已将非 Windows XP 机器上的 WebGL 成功率从 80% 提升到了 99%。这与我们在其他浏览器中看到的改进程度一致。

标准化和发布 WebGL/WebGL 2

WebGL 2 基于 OpenGL ES 3.0 规范，并提供新的功能，包括 3D 纹理和 2D 纹理数组、ESSL 3.0（一种高级着色语言）、整数纹理格式和顶点属性、变换反馈以及用于更有效上传的统一块。它还添加了图元重启、帧缓冲区清除和失效、可分离采样器对象、遮挡查询和像素缓冲区对象。此外，一些可选的 WebGL 1 扩展现在已成为 WebGL 2 保证的核心部分，包括多个渲染目标、实例化绘制、深度和浮点纹理以及 sRGB 支持。同样值得注意的是对新的 ETC2 纹理格式 的支持，该格式在压缩纹理上提供了 alpha 支持，并在台式机和移动设备上均受支持。最后，改进的垃圾回收提供了更加流畅的体验。WebGL 2 于 2017 年 1 月在 Firefox 51 中发布。

解决 32 位内存不足问题 (OOM)

对于使用编译代码库和 asm.js 的网页开发者来说，一个持续的痛点是在 32 位浏览器上遇到内存不足的情况。默认情况下，在 Windows 上，Firefox 是一个 32 位应用程序。这将 Firefox 的地址空间限制为最多 4 吉字节，随着时间的推移，这些空间往往会变得碎片化，并会阻止游戏请求足够大的分配以成功运行。

为了解决这个问题，我们提出了一种新的 大分配头。此头告诉浏览器尽力尝试在一个未碎片化的内容进程中加载文档，这将大大降低顶级浏览上下文的 OOM 失败率，即使在更大的分配上也是如此。我们的目标是确保如果跨进程导航的条件满足，网络应用程序能够可靠地分配 1 吉字节的连续地址空间。我们打算在 Firefox 53 中发布此解决方案。

另一个机会是鼓励用户使用 64 位浏览器，这允许应用程序使用大量的物理内存。这意味着地址空间耗尽（或 OOM）基本不可能发生。

现状

• 我们 72% 的 Windows 用户在 64 位 Windows 上运行 32 位 Firefox。这些用户可以切换到 64 位 Firefox。
• 25% 的用户在 32 位 Windows 上运行 32 位 Firefox。这些用户无法切换到 64 位 Firefox。
• 3% 的用户已经在运行 64 位 Firefox。

由于几乎四分之三的 Firefox 用户在 64 位 Windows 上运行 32 位 Firefox，因此有一个巨大的机会可以通过加速向 64 位的转变来提高这些用户运行大型网络应用程序的能力。因此，根据我们的 64 位计划记录，我们计划在 2017 年 8 月（Firefox 55）将 Firefox 安装程序更改为默认情况下在 64 位 Windows 上安装 64 位版本。在 64 位 Windows 上将现有 32 位 Firefox 用户升级到 64 位 Firefox 可能会在 2017 年 10 月（Firefox 56）进行。

分享关于 Firefox 硬件受众的信息

假设您正在开发一款复杂的游戏或应用程序。您可能想知道网络用户在其系统上可以使用哪些功能，或者如何覆盖尽可能广泛的受众群体？为了帮助解决这些问题，我们 最近发布了 Firefox 硬件报告 来帮助回答这些问题，并为您的开发决策提供参考。

在网站上，您会找到各种数据点，显示 Firefox 网络用户在网络上使用哪些硬件和操作系统，以及随着时间的推移的趋势。这包括 CPU 供应商、核心和速度；系统内存；GPU 供应商、型号和显示分辨率；操作系统架构和市场份额；浏览器架构份额，以及最后，Flash 插件的可用性。

结论

我们现在专注于在未来几个月内实现上述所有改进。我们感谢游戏开发者、引擎提供商以及其他浏览器的引擎团队长期以来对这项技术的贡献。这是一项巨大的工作，如果没有您的帮助和反馈，我们无法共同完成。谢谢！