Firefox Quantum 带来的超稳定 WebVR 用户体验

周二,Mozilla 发布了 Firefox Quantum,这是自我们开始计数以来 Firefox 浏览器的第 57 个版本。这个具有里程碑意义的版本用更新、更快、更现代的实现替换了一些核心浏览器组件。此外,Quantum 版本还包含了来自 Quantum Flow 的主要优化,Quantum Flow 是一项全面的努力,旨在通过识别和消除导致卡顿的主要来源来现代化并改进 Firefox 网页引擎的基础,而无需从头开始重写一切,我的同事 Lin Clark 将其描述为“浏览器性能突击队”。

Quantum Flow 对 WebVR 稳定性产生了重大而明显的影响,如以下视频所示

此视频展示了在后台运行 SpeedometerSnowglobe 演示的执行配置文件,以模拟在常规场景中多个选项卡打开的影响。

视频顶部的图表显示了几个间隙,其中线条变平。间隙的宽度代表了一段时间,在此期间浏览器无法满足 VR 系统施加的时限。如果这种情况持续时间足够长,头显将尝试将用户带到安全空间,以防止眩晕和其他令人讨厌的情况。

Firefox 55 中的间歇性闪烁对应于 VR 系统尝试将用户带到安全空间的宽间隙。请注意,在 Quantum 中,这种现象不会发生,体验更加流畅、舒适。

这种差异是由于 Quantum Flow 已经消除了干扰浏览器及时向 VR 系统发送新图像的能力的瓶颈。

要了解全面的优化如何影响虚拟现实演示,有必要了解 VR 系统的严格要求,并了解 Firefox 的通信基础设施。

VR 帧

在浏览器中,常规 3D 内容以 60 Hz 的频率显示。这意味着网页内容大约有 16.6 毫秒的时间来模拟世界、渲染场景,并将新图像发送到浏览器合成线程。如果网页满足 16.6 毫秒的时限,帧速率将保持恒定的 60 fps(每秒帧数),并且动画将流畅运行,不会出现卡顿。

上图显示了三个帧,当前帧以绿色突出显示。每条垂直线都标记帧的结束,即渲染的场景向用户显示的时刻。

VR 内容以 90 Hz 的频率显示,因此 VR 的渲染时间缩短至 11.1 毫秒。在 WebVR 中,网页内容将渲染的帧发送到专用的 WebVR 线程。

更重要的是,在 VR 中,我们应该考虑以前忽略的一个事实:网页开始渲染 VR 场景到头显中显示新图像之间的时间延迟会直接影响用户的感知。

这是因为场景在将摄像头放置在帧的开头(基于用户的头部位置)后开始渲染,但场景在稍后显示,用户有足够的时间改变他们的方向。这种延迟被称为 运动到光子 延迟,会导致眩晕和恶心。

运动到光子的影响会导致现实落后于用户的视野。

幸运的是,VR 系统可以通过在头显中显示之前扭曲渲染的场景(在称为 重投影 的过程中)来部分地解决这个问题,而不会增加延迟。

但是,延迟越低,模拟就越准确。因此,为了减少延迟长度,浏览器不会在显示上一帧后立即开始渲染。

遵循与传统帧相同的方法,运动到光子的延迟将持续整个帧。

相反,它会向 VR 系统请求一个等待时间来延迟渲染场景。

在帧的开头等待,而不改变渲染时间,会缩短运动到光子的延迟。

正如下面将讨论的,网页内容和 WebVR 线程在不同的进程中运行,但它们需要协调以渲染场景。在 Quantum Flow 之前,进程之间的通信存在潜在的瓶颈风险。在 VR 帧中,有两个关键的通信点:一个是等待后,WebVR 将执行权让给网页以渲染场景;另一个是渲染后,网页内容将帧发送到 WebVR 线程。

在任何一个中出现意外延迟都会导致运动到光子的延迟达到峰值,并且头显会拒绝该帧。

Firefox 中的进程间通信消息

Firefox 将其执行组织成多个进程:父进程,包含浏览器 UI 并可以访问系统资源;GPU 进程,专门用于与显卡通信,包含 Firefox 合成器和 WebVR 线程;以及多个内容进程,运行网页内容,但不能与系统的其他部分进行通信。这种 进程分离 使得将来可以提高浏览器安全性,并防止有问题的网页崩溃整个浏览器。

父进程、GPU 进程和内容进程使用进程间通信 (IPC) 消息相互通信。

进程之间经常需要相互通信。为了做到这一点,它们使用进程间通信 (IPC) 消息。IPC 消息包含三个部分:1) 发送请求,2) 在接收方执行任务,以及 3) 将结果返回给发起者。这些消息可以是同步的或异步的。

当任何其他 IPC 消息尝试必须等到当前通信完成时,我们就说它是同步 IPC。这包括等待发送消息、完成任务以及返回结果。

同步 IPC 意味着长时间等待和缓慢的队列。

同步 IPC 的问题是,试图与父进程通信的活动选项卡可能会阻止传递。这将强制等待,直到不同通信的结果到达发起者,即使后者是后台选项卡(因此,不紧急)或正在进行的任务与尝试的通信无关。

相反,当发送请求、执行任务和返回结果是独立操作时,我们就说它是异步 IPC。新的通信无需等待发送。执行和结果传递可以乱序发生,并且可以动态地重新排序任务。

尽管任务持续时间和旅行时间保持不变,但此动画比之前的动画短 34%。异步 IPC 不会避免队列,但它能更快地解决队列。

Quantum Flow 在 Firefox 55、56 和 57 版本中的一项目标是 识别同步 IPC 并将其转换为异步 IPCEhsan Akhgari 在他的系列文章“Quantum Flow 工程通讯”中完美地回顾了今年 Quantum Flow 计划的进展。

既然我们已经探讨了同步 IPC 带来的性能风险,让我们重新审视 VR 帧中的两个关键通信:一个是将执行权让给网页以开始渲染的通信,另一个是将帧发送到头显的通信;两者分别需要来自 GPU 到内容内容到 GPU 的 IPC。

VR 帧中的风险点每帧发生一次,即每秒 180 次。

由于 VR 帧速率,这些关键的风险时刻每秒发生 180 次。在 Firefox 55 中 Quantum Flow 的早期阶段,高帧速率以及其他打开的选项卡的后台活动增加了被正在进行的同步 IPC 请求延迟的可能性。等待时间并不少见。在这种情况下,浏览器不断错过 VR 设备施加的时限。

在 Firefox 56 和 57 中推进 Quantum Flow 工作后,正在进行的同步 IPC 移除降低了被意外通信中断的可能性,现在浏览器不会错过时限。


虽然 Quantum Flow 并非专门针对改善 WebVR,但通过消除通信瓶颈,新组件可以有效地为全局性能提升做出贡献。如果没有 Quantum Flow,无论浏览器有多快、有多新、有多现代,如果新功能和新功能被阻塞,等待无关操作完成,那都是没有意义的。

因此,Firefox Quantum 不仅是渲染 2D 内容速度最快的 Firefox 版本,也是目前为您带来最稳定、最舒适的 WebVR 观看体验的浏览器。 并且 最好的还在后头

关于 Salva

Mozilla 的前端开发人员。开放网络和 WebVR 支持者,我喜欢编程语言、电影、音乐、电子游戏和啤酒。

更多 Salva 的文章…


2 条评论

  1. Pete Markiewicz

    我在安装后,我的 FF 安装从使用 WebVR 转换为输出“无效的 FrameData” - 安装需要系统重启吗?

    2017 年 11 月 17 日 上午 11:07

  2. Koprowski.it

    我是一名 Unity VR 开发人员,正在考虑重新培训为前端开发人员。感谢您的文章,我已经开始考虑转型为… 前端 VR 开发人员!:)

    2017 年 11 月 18 日 上午 07:47

本文的评论已关闭。