作者在 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 实际上就是之前的 Tadpole 的正式称谓，这个称谓也跟 OOP-R 在命名上保持了一致。OOP-D 实际上包含了以下三个主要目标：
- 将 Display Compositor 从 Browser 进程迁移到 Viz 进程（原 GPU 进程）；
- Display Compositor 使用 SkiaRenderer 直接进行合成，不再使用 CommandBuffer；
- SkiaRenderer 的实现支持 Vulkan；
为了实现这些目标的前置任务包括：
- 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
从上图看要实现的目标包括：
- 将光栅化的 Worker 线程从 Renderer 进程转移到 Viz 进程，Renderer 进程的 RasterInterface 实际上是将序列化后的 Paint Item lists 通过 IPC 发送给 Viz 进程去做光栅化；
- Viz 进程的光栅化器使用 Skia 完成光栅化，支持 GL 和 Vulkan 的实现，不再使用 CommandBuffer；
目标一的第一个实验版本目标是 m70，而目标二还仅仅是设计和原型的阶段。
OOP-D + OOP-R
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 吧。
