BlinkOn9 - Viz Update-阿里云开发者社区

开发者社区> 开发与运维> 正文

BlinkOn9 - Viz Update

简介:

作者在 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

OOP-D 实际上就是之前的 Tadpole 的正式称谓,这个称谓也跟 OOP-R 在命名上保持了一致。OOP-D 实际上包含了以下三个主要目标:

  1. 将 Display Compositor 从 Browser 进程迁移到 Viz 进程(原 GPU 进程);
  2. Display Compositor 使用 SkiaRenderer 直接进行合成,不再使用 CommandBuffer;
  3. SkiaRenderer 的实现支持 Vulkan;

oopif compositing

为了实现这些目标的前置任务包括:

  1. Surface Synchronization —— 用于支持多个不同进程的 Viz Client(ClientLayerTreeFrameSink) 给 Display Compositor 提交的 CompositorFrame 的同步,这个情况会存在于 Browser 进程提交的 UI 界面的 CompositorFrame 和 Renderer 进程提交的网页内容的 CompositorFrame 的合成,还有在支持 Site Isolation 后,多个 Renderer 进程提交的主 frame 和不同 origin 的 iframe 的 CompositorFrame 的合成(参考上图);
  2. New Event Targeting - 了解的不多,看起来是为了解决 Site Isolation 支持后的事件路由的问题;
  3. Enhanced Draw Occlusion - OOP-D 会导致 Site Isolation 的网页 Overdraw 增加,增强的绘制遮挡剔除主要是解决这个问题;

完成以上任务,第一个包括前两个目标和初步的 Vulkan 验证实现的实验版预计会在 m69 上上线。

OOP-R

oop-r

从上图看要实现的目标包括:

  1. 将光栅化的 Worker 线程从 Renderer 进程转移到 Viz 进程,Renderer 进程的 RasterInterface 实际上是将序列化后的 Paint Item lists 通过 IPC 发送给 Viz 进程去做光栅化;
  2. Viz 进程的光栅化器使用 Skia 完成光栅化,支持 GL 和 Vulkan 的实现,不再使用 CommandBuffer;

目标一的第一个实验版本目标是 m70,而目标二还仅仅是设计和原型的阶段。

OOP-D + OOP-R

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 吧。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章