摘要：前段時間我寫了一篇文章瀏覽器渲染流水線解析與網(wǎng)頁動畫性能優(yōu)化，對目前 60 左右版本的 Chrome 的渲染流水線進(jìn)行解析，文末也討論了當(dāng)前渲染流水線的一些不足和未來演化的方向。 當(dāng)前的渲染流水線過于復(fù)雜和冗長，特別是對于非合成器動畫來說，過多的線程/進(jìn)程間交互增加了不少額外開銷，異步光柵化的機(jī)制也是有利于合成器動畫而不利于非合成器動畫。

前段時間我寫了一篇文章瀏覽器渲染流水線解析與網(wǎng)頁動畫性能優(yōu)化，對目前 60 左右版本的 Chrome 的渲染流水線進(jìn)行解析，文末也討論了當(dāng)前渲染流水線的一些不足和未來演化的方向。

當(dāng)前的渲染流水線過于復(fù)雜和冗長，特別是對于非合成器動畫來說，過多的線程/進(jìn)程間交互增加了不少額外開銷，異步光柵化的機(jī)制也是有利于合成器動畫而不利于非合成器動畫。而未來的演化理應(yīng)需要簡化渲染流水線，減少線程/進(jìn)程間交互，避免非必要的額外開銷，光柵化和合成不再像現(xiàn)在一樣涇渭分明，渲染流水線可以支持更靈活和動態(tài)自適應(yīng)的圖層化和光柵化策略，根據(jù)硬件的能力和性能，還有頁面的繪制特征采取不同的圖層化和光柵化方式，從而最大化頁面的動畫性能。

最近通過閱讀 Chrome 官方的一些文檔，對 Chrome 渲染流水線未來演化的一些細(xì)節(jié)也有了更多認(rèn)識。本文主要針對最近一次 Blinkon 上的演講?What is Viz: The Future of Chrome Compositing?進(jìn)行解讀（如果該網(wǎng)址無法訪問，可以從作者的 Github?上下載完整的 Slides），回饋對此感興趣的讀者。

FBI WARNING
個人解讀不保證絕對正確

1 Servicification

Chrome 渲染流水線的演化是在 Chrome 整個系統(tǒng)架構(gòu)演化的大背景下發(fā)生的，官方稱這個過程為 Servicification，釋義來自于維基百科：

Servicification is “the migration from monolithic legacy applications into service-based components”

對 Chrome 來說，就是：

Splitting a monolithic Chrome browser up into components.

也就是說 Chrome 整體架構(gòu)會朝向現(xiàn)代 OS 所采用的 SOA (Services Oriented Architecture) 方向發(fā)展，原來的各種模塊會被重構(gòu)成獨(dú)立的 Services，每個 Service 都可以運(yùn)行在獨(dú)立進(jìn)程，訪問 Services 必須通過定義好的接口，通過 IPC 進(jìn)行通訊，從而構(gòu)建一個更內(nèi)聚，松耦合，易于維護(hù)和擴(kuò)展的系統(tǒng)，更好實(shí)現(xiàn) Chrome 的目標(biāo)：

• Speed
• Simplicity
• Security
• Stability

Chrome 的渲染相關(guān)模塊最終會重構(gòu)成兩個 Services，一個負(fù)責(zé)非網(wǎng)頁部分繪制的 UI Service，包括瀏覽器的 UI 界面，Chrome OS 的 GUI 界面等；一個負(fù)責(zé)網(wǎng)頁部分繪制的 Service，也就是本文主要討論的 Viz。

Chrome 整個系統(tǒng)架構(gòu)演化這個題目太過龐大，本文不再過多討論，感興趣的讀者可以閱讀官方的這篇文檔 ——?Chrome Service Model。

2 Viz

Viz 是 Visuals 的簡寫，按照規(guī)劃：

GPU 進(jìn)程被改造成 Viz 進(jìn)程，用于運(yùn)行 Viz Service；

分布在其它進(jìn)程的跟渲染有關(guān)的光柵化，多級合成器等，最終都會被整合到 Viz Service，統(tǒng)一運(yùn)行在 Viz 進(jìn)程；

最終要達(dá)成的目標(biāo)：

實(shí)現(xiàn) Chrome Servicification 的架構(gòu)目標(biāo)，Service 內(nèi)部更內(nèi)聚，跟外部的關(guān)系更松耦合；

光柵化，合成，GPU 調(diào)用等全部匯集在同一個 Service 內(nèi)部，統(tǒng)一在同一個進(jìn)程，使得 Chrome 可以對渲染流水線進(jìn)行重組和簡化，減少不必要的開銷，提高整體效率；

上圖顯示了 Chrome 當(dāng)前的渲染流水線：

GPU 進(jìn)程的用途是實(shí)現(xiàn)對 GPU 的虛擬化封裝，其它進(jìn)程可以通過 Command Buffer（可以看做是 Chrome 提供的一個 Virtual GL Context）跨進(jìn)程地訪問 GPU，Command Buffer 通過支持跨進(jìn)程，帶來了更好的安全性和健壯性，但是也引入了一定的額外開銷；

光柵化和 Layer Compositor 運(yùn)行在 Renderer 進(jìn)程，光柵化器（GPU 光柵化）通過 Command Buffer 跨進(jìn)程訪問 GPU；

Display Compositor 運(yùn)行在 Browser 進(jìn)程，同樣通過 Command Buffer 跨進(jìn)程訪問 GPU；

Viz 改造是逐步進(jìn)行的，每一階段會實(shí)現(xiàn)一些新特性，本文后續(xù)的部分會對這些新特性的內(nèi)容進(jìn)行介紹。

2.1 Tadpole - Direct Compositing

Direct Compositing 實(shí)際包含前后兩個步驟：

首先是 Display Compositor 要從 Browser 進(jìn)程遷移到 Viz 進(jìn)程（原 GPU 進(jìn)程）；

然后 Display Compositor 原來使用的 GLRenderer 會替換成新的 SkiaRenderer，SkiaRenderer 直接使用 Native GL 而不是通過 Command Buffer 封裝的 Virtual GL；

Direct Compositing 預(yù)計能帶來 10% - 15% 左右的性能提升，減少了進(jìn)程間交互和 Command Buffer 帶來的額外開銷。在這個過程中 Renderer 進(jìn)程保持不變。

2.2 OOP Rasterization

OOP 是 Out of Process 的縮寫，所謂 OOP Rasterization 就是將光柵化從 Renderer 進(jìn)程遷移到 Viz 進(jìn)程。

原來的光柵化器（GPU 光柵化）運(yùn)行在 Renderer 進(jìn)程，它將 2D 繪圖指令轉(zhuǎn)換成 GL 繪圖指令通過 Command Buffer 交給 GPU 進(jìn)程運(yùn)行。OOP Rasterization 后，位于 Renderer 進(jìn)程的 Layer Compositor 需要支持 2D 繪圖指令的序列化和反序列化，將 2D 繪圖指令傳遞到 Viz 進(jìn)程執(zhí)行。

OOP Rasterization 處于跟 Direct Compositing 并行開發(fā)的階段，并最終會進(jìn)行融合。融合后的結(jié)果如上圖，光柵化器（GPU 光柵化）和 Display Compositor 同樣使用 SkiaRenderer，直接調(diào)用 Native GL 而不是通過 Command Buffer 封裝的 Virtual GL。

2.3 Vulkan

Command Buffer 基本上是以 GL 為模板設(shè)計出來的，API 跟 GLES 也保持一一對應(yīng)，這也意味著很難讓 Command Buffer 同時也支持 Vulkan。Chrome 引入對 Vulkan 的支持主要是通過 Skia，SkiaRenderer 或者 Skia Ganesh Compositor（抱歉我也搞不清到底哪個會是最后官方的稱謂）會同時支持使用 GL 或者 Vulkan 作為 Backend，根據(jù)設(shè)備的硬件能力進(jìn)行選擇。

預(yù)計使用 Vulkan 比起使用 GL 會帶來 10 - 15% 的性能提升。

2.3.1 WebGL

對于 WebGL 來說，為了保證在 Renderer 進(jìn)程使用 GPU 的安全性和健壯性，WebGL 對 GL 的調(diào)用還是一樣要通過 Command Buffer。后端的實(shí)現(xiàn)可能有兩種方式，一種是后端仍然在一個獨(dú)立的 GL Context 上使用 GL，然后 WebGL 繪制的 FrameBuffer 通過平臺相關(guān)的 API share 到 Vulkan Context；另外一種是通過 Angle for Vulkan (aka Vangle) 將 GL 指令轉(zhuǎn)換成 Vulkan 指令在 Vulkan Context 上運(yùn)行，個人猜測移動平臺上多半是前者。

2.4 Salamander - Central Layerization

Salamander 是目前規(guī)劃的 Viz 改造的最后階段：

Layer Compositor 從 Renderer 進(jìn)程遷移到 Viz 進(jìn)程，并和 Display Compositor 融合成 Unified Compositor；

Renderer 發(fā)送給 Viz 的數(shù)據(jù)只包括每一個排版對象的繪圖指令，和攜帶圖層數(shù)據(jù)的 Property Trees，Unified Compositor 根據(jù)這些數(shù)據(jù)和其它信息來決定最終的圖層化策略；

OOPIF 的繪制得到更好的支持，避免不必要的光柵化和合成；

雖然官方的文檔沒有說明，但是個人覺得在這里 Unified Compositor 可以根據(jù)需要選擇不同的光柵化策略，比如為個別圖層分配 Offscreen Buffer，采用 ASync 或者 On Demand Rasterization 的光柵化策略；而另外一些圖層則不分配 Buffer，采用 Direct Rasterization 的光柵化策略；

3 Summary

3.1 Viz Status

正在進(jìn)行中

• Tadpole: relocate the DisplayCompositor to Viz in 66
• OOP Rasterization in Viz Q2 2018
• SkiaRenderer in 67

2018 Q3 之后開始

• Vulkan graphics
• Salamander: central layerization

整個過程還是相當(dāng)漫長，目前有明確的版本規(guī)劃的只是 67 的 Direct Composting，其它只有大概的時間規(guī)劃，還沒有明確會在哪個版本 Landing。

3.2 Viz Take-aways

從兩個角度思考 Viz：

Chrome 圖形子系統(tǒng)的 Servicification 過程；

更好的 GPU 進(jìn)程；

Viz 從下面三個方面帶來渲染性能的提升：

10 - 15% 的性能提升來自于移除不必要的 Command Buffer 的使用；

10 - 15% 的性能提升來自于對 Vulkan 的支持；

對 OOPIF 繪制的更好支持，避免不必要的光柵化和合成；

作者：小扎zack 原文地址

識別以下二維碼，干貨

總結(jié)

以上是生活随笔為你收集整理的Chrome 渲染流水线演化的未来的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。