RenderingNG

迎接新一代的網路內容

Chris Harrelson

RenderingNG 是新一代算繪架構，效能遠勝先前版本。RenderingNG 的建構時間超過八年，代表著許多專業 Chromium 開發人員的共同努力。這項技術可為快速、流暢、可靠、回應迅速且具互動性的網路內容開啟無限潛力。

RenderingNG

本文將說明我們建構的內容、建構原因，以及運作方式。

北極星目標

RenderingNG 的北極星目標是，瀏覽器引擎實作方式和其轉譯 API 的豐富程度，不應成為網頁使用者體驗的限制因素。

您不必擔心瀏覽器錯誤會導致功能不穩定，或導致網站無法正常轉譯。

不應出現不明原因的效能下滑情形。而且，您不必因應缺少的內建功能而調整。

應該會正常運作。

這項計畫是朝向這個北極星目標邁進的重要一步。在 RenderingNG 推出之前，我們可以 (而且確實) 新增算繪功能並改善效能，但很難讓這些功能對開發人員可靠，而且效能也經常出現斷崖。我們現在採用的架構可有系統地解決許多問題，並且解除先前認為不可行的進階功能。其中包括：

• 在不同平台、裝置和作業系統組合中提供穩固的核心功能。
• 具備可預測且可靠的效能。
• 盡可能使用硬體功能 (核心、GPU、螢幕解析度、更新率、低階光柵 API)。
• 只執行顯示可見內容所需的工作。
• 內建支援常見的視覺設計、動畫和互動設計模式。
• 提供開發人員 API，方便管理轉譯成本。
• 為開發人員外掛程式提供轉譯管道擴充點。
• 可針對所有內容進行最佳化，包括 HTML、CSS、2D 畫布、3D 畫布、圖片、影片和字型。

與其他瀏覽器轉譯引擎的比較

Gecko 和 WebKit 也實作了這些網誌文章中所述的大部分相同架構功能，在某些情況下甚至比 Chromium 更早加入這些功能。

任何瀏覽器的速度和可靠性提升，都是值得慶祝的喜訊，也能帶來實際影響。最終目標是提升所有瀏覽器的基準，讓開發人員能信賴這些基準。

成功金字塔

我的理念是，要想成功，就必須先達成可靠性，然後是可擴充的效能，最後是可擴充性。

就像現實生活中的金字塔一樣，每個層級都為上層提供必要的穩固基礎。

可靠性

如要提供豐富且複雜的使用者體驗，我們首先需要的是穩固的平台。核心功能和基礎架構必須正常運作，並持續運作。同樣重要的是，這些功能必須能良好組合，且不會出現奇怪的邊緣情況行為或錯誤。

因此，穩定性是 RenderingNG 最重要的部分。可靠性則是良好測試、優質的意見回饋循環、指標和軟體設計模式的結果。

為了讓大家瞭解我認為可靠性有多重要，我們在過去八年大部分的時間都專注於這個部分。首先，我們深入瞭解系統的運作方式，從錯誤報告中找出弱點並加以修正，啟動全面測試，並瞭解網站的效能需求和 Chromium 效能的限制。接著，我們仔細地逐步設計並推出主要設計模式和資料結構。只有在那個時候，我們才準備好為回應式設計、可擴充性和算繪自訂化，新增真正新一代的基礎元素。

這並非表示 Chromium 在那段期間沒有任何改善。事實上，反之亦然！在那段期間，我們逐步重構並推出各項改善措施，可靠性和效能持續提升。

測試和指標

過去 8 年來，我們新增了數萬個單元、效能和整合測試。此外，我們也開發了全面的指標，可評估 Chromium 在本機測試、效能基準測試，以及實際網站上實際使用者和裝置的運算行為。

不過，無論 RenderingNG (或其他瀏覽器的轉譯引擎) 有多強大，如果瀏覽器之間存在許多錯誤或行為差異，開發人員仍無法輕鬆為網頁進行開發。為解決這個問題，我們也會盡可能使用網頁平台測試。每項測試都會驗證網站平台的使用模式，所有瀏覽器都應以通過測試為目標。我們也會密切監控指標，隨著時間的推移通過更多測試，並提高核心相容性。

Web Platform 測試是一項合作計畫。舉例來說，Chromium 工程師只新增了 CSS 功能的 10% 總 WPT 測試；其他瀏覽器供應商、獨立貢獻者和規格作者則負責其餘的部分。我們需要集結眾人之力，才能打造可互通的網路！

根據 wpt.fyi/compat2021 的測試，評估 WPT 針對核心功能的通過率

良好的軟體設計模式

如果程式碼易於理解，並以盡可能減少錯誤的設計方式進行編寫，就能更輕鬆地提供可靠的優質軟體。我們會在後續的網誌文章中，進一步說明 RenderingNG 的軟體設計。

可調整的效能

在速度、記憶體和電力使用量等方面，達成出色的效能，是 RenderingNG 的次要重點。我們希望與所有網站的互動都能順暢且即時回應，但不會犧牲裝置的穩定性。

但我們不只想要效能，我們想要的是可擴充的效能，也就是在低階和高階機器上，以及跨作業系統平台上，都能穩定發揮效能的架構。我稱之為「向上調整」(利用硬體裝置可達成的所有功能) 和「向下調整」(盡可能提高效率，並在必要時降低系統需求)。

為達到這個目標，我們需要盡可能善用快取、效能隔離和 GPU 硬體加速功能。我們來逐一探討。為了讓這項概念更具體，我們來思考一下，每個因素如何影響網頁上一個非常重要的互動：捲動。

快取

在動態互動式 UI 平台 (例如網頁) 中，快取是大幅改善效能的唯一重要方法。瀏覽器中最常見的快取類型是 HTTP 快取，但轉譯也有許多快取。捲動畫面時最重要的快取是快取的 GPU 材質和顯示清單，可讓捲動畫面時速度極快，同時盡量減少電池耗電量，並在各種裝置上正常運作。

快取可延長電池續航力，並提高捲動動畫的幀率，但更重要的是，它可解除主執行緒的效能隔離。

效能隔離

在現代化的電腦上，您不必擔心背景應用程式會拖慢您正在使用的應用程式。這是因為預先執行多工作，這也是一種效能隔離形式：確保獨立工作不會互相拖慢。

在網路上，捲動畫面是最佳的效能隔離範例。即使網站的 JavaScript 速度緩慢，捲動畫面也能非常順暢，因為這項功能會在不同的執行緒上執行，不必依賴 JavaScript 和版面配置執行緒。我們在 RenderingNG 上投入大量心力，確保每個可能的捲動動作都會以多執行緒執行，並透過快取功能，將顯示清單的複雜度提升至更高層級。例如代表固定和固定位置元素的程式碼、被動事件監聽器，以及高品質文字轉譯。

GPU 加速

GPU 可大幅加快產生像素及繪製至螢幕的速度。在許多情況下，每個像素都能與其他像素並行繪製，因此速度會大幅提升。RenderingNG 的關鍵元件是 GPU 光柵和隨處繪製。這項功能會在所有平台和裝置上使用 GPU，以便加速轉譯及動畫化網頁內容。這點對於低階或高階裝置尤其重要，因為這類裝置的 GPU 通常比裝置的其他部分更強大。

可擴充性：適合工作需求的工具

在確保穩定性和可擴充的效能後，我們現在可以利用多項工具，協助開發人員擴充 HTML、CSS 和 Canvas 內建的部分，且不會犧牲任何辛苦獲得的效能和穩定性。

其中包括內建的 API 和 JavaScript 公開 API，可用於回應式設計、漸進式算繪、流暢度和回應速度，以及多執行緒算繪等進階用途。

以下是 Chromium 大力提倡的開放式網路 API，這些 API 原本被視為不可能實現，但現在則得益於 RenderingNG 而得以實現。

這些功能都是根據開放規格開發，並與開放網路合作夥伴 (其他瀏覽器的工程師、專家和網頁開發人員) 合作開發。在後續的網誌文章中，我們將深入探討這些功能，並說明 RenderingNG 如何實現這些功能。

• content-visibility：讓網站輕鬆避免為畫面外內容進行轉譯作業，並快取目前未顯示的單頁應用程式檢視畫面的轉譯作業。
• OffscreenCanvas：可讓畫布轉譯 (包括 2D 畫布 API 和 WebGL) 在其專屬執行緒上執行，以確保可靠的優異效能。這個專案也是網頁的另一個重大里程碑，因為這是第一個允許 JavaScript (或 WebAssembly) 從多個執行緒轉譯單一網頁文件的網頁 API。
• 容器查詢：允許單一元件以回應式方式自行版面配置，解除整個即插即用元件的封鎖 (目前為實驗性質的實作)。
• 來源隔離：允許網站選擇在 iframe 之間進行更多成效隔離。
• 主執行緒外繪圖工作項：開發人員可透過在轉譯器執行緒上執行的程式碼，擴充元素的繪圖方式。

除了明確的網頁 API 之外，RenderingNG 也讓我們能夠提供多項對所有網站都有益的「自動功能」：

• 網站隔離：將跨來源 iframe 放入不同的 CPU 程序，以提升安全性和效能隔離。
• Vulkan、D3D12 和 Metal：利用較低層級 API 的優勢，比 OpenGL 更有效率地使用 GPU。
• 更多合成的動畫：SVG、背景顏色。

RenderingNG 解除封鎖的其他即將推出的功能，包括：

• 捲動連結動畫。
• 隱藏但可搜尋及存取的 DOM。
• 共用元素轉場效果。
• 自訂版面配置。
• 主執行緒外合成；分離執行緒和合成。

組成 RenderingNG 的主要專案

以下是 RenderingNG 中的主要專案清單。

CompositeAfterPaint

CompositeAfterPaint 會將合成作業與樣式、版面配置和繪製作業分開，讓可靠性和可預測的效能大幅提升，並提高傳輸量，同時減少記憶體用量，而不犧牲效能。

年	進度
2015	傳送顯示清單。
2017	傳送新的無效化。
2018	船舶資源樹狀結構 1。
2019	船舶資源樹狀結構，第 2 部分。
2021	已完成專案運送。

LayoutNG

從頭開始重寫所有版面配置演算法，大幅提升可靠性，並提供更可預測的效能。

進一步瞭解 LayoutNG。

年	進度
2019	發布區塊流程。
2020	提供彈性，可供編輯。
2021	運送其他所有內容。

BlinkNG

我們已重構並清理Blink 轉譯引擎，將其分成清楚分隔的管道階段。這可提供更優異的快取、更高的可靠度，以及重疊或延遲轉譯功能，例如內容可見度和容器查詢。

隨處 GPU 加速

由於每個像素都能並行處理，因此 GPU 加速可為大多數內容提供極大的速度提升。這也是改善低階裝置效能 (通常仍有 GPU) 的有效方法。

年	進度
2014	支援無框畫。在 Android 上針對選擇加入的內容發布。
2016	在 Mac 上發布。
2017	超過 60% 的 Android 網頁瀏覽次數都會使用 GPU。
2018	在 Windows、ChromeOS 和 Android Go 上發布。
2019	執行緒化 GPU 光柵化。
2020	發布剩餘的 Android 內容。

分割捲動、動畫和解碼

長期努力將所有捲動、非版面配置誘發動畫和圖片解碼作業移出主執行緒。這項工作仍在進行中。

年	進度
2011	初步支援分割捲動和動畫。
2015	圖層壓縮。
2016	通用溢位捲動功能。
2017	在合成器執行緒上解碼圖片。
2018	在合成器執行緒上顯示圖像動畫。
2020	一律合成固定位置。
2021	百分比轉換動畫、SVG 動畫。

Viz

這是 Chromium 的集中式光柵和繪圖程序，可提高處理量、最佳化記憶體，並讓硬體功能發揮最佳效益。這項功能還有其他好處，雖然網頁開發人員較少接觸，但使用者卻能明顯感受到，例如解除網站隔離功能的封鎖，以及將轉譯管道與瀏覽器 UI 轉譯作業解耦。

年	進度
2018	OOP-R 已在 Android、Mac 和 Windows 上發布。
2019	OOP-D 已出貨。OOP-R 已在所有地區推出 (Canvas 除外)。在 Linux 上提供 SkiaRenderer。
2020	SkiaRenderer 已在 Windows 和 Android 上發布。在 Android 上推出 Vulkan。
2021	SkiaRenderer 已在 Mac 上推出 (ChromeOS 也即將推出)。

上方圖表中各項條件的定義：

OOP-D

離線顯示合成器。顯示合成是與作業系統合成器相同類型的活動。這表示在 Viz 程序中執行，而非在網頁的轉譯程序或瀏覽器 UI 程序中執行。

OOP-R

離線處理算繪。轉成點陣圖會將顯示清單轉換為像素。這表示在 Viz 程序中執行，而非在網頁的轉譯程序中執行。

SkiaRenderer

新的顯示器合成器實作項目，可支援在各種不同的基礎 GPU API 上執行，例如 Vulkan、D3D12 或 Metal。

以多執行緒和加速方式轉譯無框畫

這是讓 OffscreenCanvas 成為可能的專案。

年	進度
2018	傳送 OffscreenCanvas。
2019	傳送 ImageBitmapRenderingContext。
2021	出貨 OOP-R。

VideoNG

VideoNG 是長期努力的成果，可在網路上提供高效、可靠且高品質的影片播放服務。

年	進度
2014	推出以 Mojo 為基礎的轉譯架構。
2015	提供 Project Butter 和影片疊加功能，讓影片算繪更順暢。
2016	推出統一的 Android 和電腦解碼及轉譯管道。
2017	已發布 HDR 和經過色彩校正的影片算繪功能。
2018	已發布以 Mojo 為基礎的影片解碼管道。
2019	已發布以 Surface 為基礎的影片轉譯管道。
2021	在 ChromeOS 上提供4K 受保護內容轉譯支援功能。

上方圖表中各項條件的定義：

Mojo

Chromium 的新一代 IPC 子系統。

Surface

屬於 Viz 專案設計的概念。

---

插圖由 Una Kravets 提供。