作者在 4 月 18~19 期间和同事一起在湾区参加了为其两天的 BlinkOn 9 会议。每次 BlinkOn 都是了解当前 Blink & Chrome 和 Web 技术演进现状和发展方向的一个不错机会,两天的会议下来大概听了 6 ~ 7 场分享,有些主题是之前已经有所了解,这次又更新了最新的进展信息;有些主题则是完全陌生,在这次 BlinkOn 上才第一次知悉。作者接下来会撰写一系列文章,每篇文章针对一个特定的主题,尽可能把相关的信息回馈给读者。
BlinkOn9 关于 Chrome 新的渲染引擎 Viz 的分享 Chrome Graphics: Viz Update 实际的内容并不多,只是对半年前 BlinkOn8 上 What is Viz: The Future of Chrome Compositing 分享后的一些信息更新,针对 BlinkOn8 上分享的解读,建议读者可以先看作者的这篇文章 - Chrome 渲染流水线演化的未来,这样更容易理解本文的内容。
这次分享的内容主要是关于 OOP-D (Out of Process Display Compositor)和 OOP-R (Out of Process Rasterization) 的当前进展,和对 OOP-D 和 OOP-R 完成融合后的最终状态的描绘。
OOP-D
![oop-d](http://static.zybuluo.com/rogeryi/rht0b12203yxdt1lm627wb54/image.png?x-oss-process=image/resize,w_1400/format,webp)
OOP-D 实际上就是之前的 Tadpole 的正式称谓,这个称谓也跟 OOP-R 在命名上保持了一致。OOP-D 实际上包含了以下三个主要目标:
- 将 Display Compositor 从 Browser 进程迁移到 Viz 进程(原 GPU 进程);
- Display Compositor 使用 SkiaRenderer 直接进行合成,不再使用 CommandBuffer;
- SkiaRenderer 的实现支持 Vulkan;
![oopif compositing](http://static.zybuluo.com/rogeryi/0rwbgfpnvi8vnmyxzkk0luvi/image.png?x-oss-process=image/resize,w_1400/format,webp)
为了实现这些目标的前置任务包括:
- Surface Synchronization —— 用于支持多个不同进程的 Viz Client(ClientLayerTreeFrameSink) 给 Display Compositor 提交的 CompositorFrame 的同步,这个情况会存在于 Browser 进程提交的 UI 界面的 CompositorFrame 和 Renderer 进程提交的网页内容的 CompositorFrame 的合成,还有在支持 Site Isolation 后,多个 Renderer 进程提交的主 frame 和不同 origin 的 iframe 的 CompositorFrame 的合成(参考上图);
- New Event Targeting - 了解的不多,看起来是为了解决 Site Isolation 支持后的事件路由的问题;
- Enhanced Draw Occlusion - OOP-D 会导致 Site Isolation 的网页 Overdraw 增加,增强的绘制遮挡剔除主要是解决这个问题;
完成以上任务,第一个包括前两个目标和初步的 Vulkan 验证实现的实验版预计会在 m69 上上线。
OOP-R
![oop-r](http://static.zybuluo.com/rogeryi/4cs68uh64bbysfneysam03ib/image.png?x-oss-process=image/resize,w_1400/format,webp)
从上图看要实现的目标包括:
- 将光栅化的 Worker 线程从 Renderer 进程转移到 Viz 进程,Renderer 进程的 RasterInterface 实际上是将序列化后的 Paint Item lists 通过 IPC 发送给 Viz 进程去做光栅化;
- Viz 进程的光栅化器使用 Skia 完成光栅化,支持 GL 和 Vulkan 的实现,不再使用 CommandBuffer;
目标一的第一个实验版本目标是 m70,而目标二还仅仅是设计和原型的阶段。
OOP-D + OOP-R
![oop-d + oop-r](http://static.zybuluo.com/rogeryi/ow9m317v3izrl6ygn893zv6w/image.png?x-oss-process=image/resize,w_1400/format,webp)
OOP-D 和 OOP-R 都实现后,唯一会使用 CommandBuffer 就只剩下 WebGL,其它需要访问 GPU API 的部分都已经从 Browser 和 Renderer 进程转移到了 Viz 进程,除了 WebGL 外,其它功能对 GPU 的使用最终都会通过 Skia,包括光栅化和合成,RasterInterface 和 ClientLayerTreeFrameSink 分别对应了光栅化和合成的 Viz Client 接口,供 Viz 的客户端使用。
这次分享没有包括 Unified Compositor 的内容,恐怕光是 OOP-D + OOP-R 要完成一个完整稳定的实现就需要花很长的时间,估计最少也要到明年上半年。
更多关于光栅化的信息
分享后的 Q&A 环节,我问了一直比较关心的关于光栅化的问题,问题是 —— “Firefox 新的渲染引擎 WebRender 看起来会使用 Direct Rasterization(直接光栅化),Chrome 是否也会走同样的路线,或者采用更灵活的混合策略,部分图层使用直接光栅化,部分图层使用异步光栅化?”
虽然 Chromium 的工程师也同样赞同对于 Web App 来说,大部分图层,比如切换的卡片,弹入弹出的侧栏菜单,中间滚动的长列表列表项,它们的内容都并不复杂,只要做好图片预解码或者延迟解码,在支持 GPU 光栅化的条件下采用直接光栅化可以带来更好的动画性能,不过他的回复是考虑到要实现直接光栅化可能的工作量,现在暂时还没有相应的计划。看起来目前的重中之重还是 OOP-D + OOP-R 吧。