準備好迎接新一代的網路內容
RenderingNG 是新一代的轉譯架構，效能遠勝以往。RenderingNG 已經過八年以上，代表許多專門 Chromium 開發人員的合作成果。它具有大量潛力，可實現快速、流暢、可靠、回應式和互動式的網路內容。
本課程將說明我們建構的內容、建構的原因，以及運作方式。
北極星進球
想實現 RenderingNG 的目標，在於瀏覽器引擎的實作方式以及轉譯 API 的豐富程度，不應做為網路使用者體驗的限制因素。
因此，您不需要擔心瀏覽器發生錯誤，會導致功能不穩定，或是網站的算繪作業中斷。
不會有神秘的效能驟降。 此外，您應該不需要解決缺少的內建功能。
應該就能順利使用。
RenderingNG 是朝著北極星目標邁進一大步。在 RenderingNG 之前，我們就能 (也確實) 新增算繪功能並改善效能，但難以確保這些功能為開發人員提供可靠，而且效能開始出現許多阻礙。現在，我們建立了有系統性地壓縮許多這類問題的架構，並且解除封鎖先前不可行的進階功能。簡要說明如下：
- 在各種平台、裝置和作業系統上提供強大核心功能。
- 效能可預測且可靠。
- 盡可能使用硬體功能 (核心、GPU、螢幕解析度、刷新率、低階光柵 API)。
- 只執行顯示可見內容所需的工作。
- 內建常見視覺設計、動畫和互動設計模式的支援。
- 提供開發人員 API，輕鬆管理算繪成本。
- 為開發人員外掛程式提供轉譯管道擴充功能點。
- 對所有內容 (HTML、CSS、2D Canvas、3D 畫布、圖片、影片和字型) 進行最佳化調整。
與其他瀏覽器轉譯引擎比較
Gecko 和 Webkit 也已實作這些網誌文章中提到的大部分架構功能，在某些情況下甚至在 Chromium 之前已新增這些功能。
任何瀏覽器越來越快可靠，都是我們舉辦慶祝活動的原因，也帶來了實質影響。最終目標是發展所有瀏覽器的基準，讓開發人員能夠依循這個基準。
成功的金字塔
我的理念是，成功才是讓機構達成可靠性，再進一步擴充效能，最後提升擴充性。
就像現實生活的金字塔一樣，每個關卡都能為上述關卡提供穩固的基礎。
可靠性
如果完全不提供豐富且複雜的使用者體驗，我們首先需要的就是穩固的平台。核心功能與基礎配置必須能正常運作，且會隨著時間持續運作。請同樣重要的是，這些功能可妥善配置，且不會執行奇怪的極端情況或錯誤。
因此，可靠性是 RenderingNG 最重要的部分。而「可靠性」則是由良好的測試、品質意見回饋循環、指標和軟體設計模式產生的結果。
過去八年來，我們花了許多時間處理這部分，對於我認為可靠性的重要性。首先，我們建立深入瞭解系統的知識，透過錯誤報告瞭解弱點並加以修正、啟動全面測試，並瞭解網站的效能需求和 Chromium 效能限制。接著，我們精心設計並逐步推出重要的設計模式和資料結構。唯有如此，我們才能著手新增真正新一代的基本功能，以打造回應式設計、擴充性和自訂轉譯功能。
這表示 Chromium 在該段時間內沒有改善。 事實上，相反地！ 這些年來，隨著我們逐步重構及推出各項改善措施，可靠性和效能表現穩定且持續攀升。
測試與指標
過去 8 年來，我們新增了數萬個單元、效能和整合測試。此外，我們也開發了全方位的指標，用於評估 Chromium 在本機測試中、效能基準和實際網站、實際使用者和裝置方面的許多算繪行為。
但是，無論 RenderingNG (或其他瀏覽器的轉譯引擎) 有多麼強大，如果瀏覽器之間出現大量錯誤或行為差異，仍然難以為網路開發出奇心。為解決這個問題，我們也會盡可能使用網路平台測試。每項測試都會驗證所有瀏覽器應通過的網頁平台使用模式。我們也會密切監控多項指標，以便持續通過更多測試和提高核心相容性。
Web Platform Tests 是一項合作計畫。舉例來說，針對 CSS 功能的所有 WPT 測試，Chromium 工程師只新增了約 10% 的成果，其他瀏覽器供應商、獨立貢獻者和規格作者則能貢獻一己之力。打造互通性的網路環境，是仰賴眾人之力！
良好的軟體設計模式
穩定提供優質軟體，如果程式碼易於理解，且設計時能盡量降低發生錯誤的可能性，就會大幅簡化。我們會在後續的網誌文章中進一步說明 RenderingNG 的軟體設計。
可擴充的效能
在速度、記憶體和耗電量等各方面獲得良好效能，是 RenderingNG 的下一個重要面向。我們希望與所有網站互動時，都能流暢且快速回應，但同時不犧牲裝置的穩定性。
然而，我們想要的是效能，我們想要的是可擴充的效能，這個架構能在低端和高階機器以及各種 OS 平台上穩定執行，可靠運作。我稱之為向上擴充，充分運用硬體裝置可達到的成果以及縮減資源，將效率提高，並在需要時減少系統上的需求。
為了達到這個目標，我們必須充分運用快取、效能隔離和 GPU 硬體加速功能。以下逐一介紹明確地說，以下就來探討這些動作對於網頁上的一次重要互動效能有何影響：捲動頁面。
快取
在網頁等動態的互動式 UI 平台上，快取是可大幅改善效能最重要的單一方法。瀏覽器中最常見的快取類型是 HTTP 快取，但轉譯作業也有許多快取。要捲動的最重要快取是快取的 GPU 紋理和顯示清單，這可提升捲動速度極快，同時可在多種裝置上降低電池耗電量及運作順暢。
快取對於捲動時的電池續航力和動畫影格速率，但更重要的是，這麼做可解除封鎖主執行緒之間的效能隔離。
效能區隔
在新式電腦上，您不必擔心背景應用程式會拖慢工作速度。這是因為先佔的多工處理功能會轉變為效能隔離的形式：確保獨立工作不會彼此執行速度變慢。
在網站上，效能隔離的最佳例子就是捲動畫面。即使是在含有大量 JavaScript 速度緩慢的網站上，捲動作業也可能非常順暢，因為這類程式碼會在不同的執行緒上執行，無須依賴 JavaScript 和版面配置執行緒。我們投入大量心力，讓 RenderingNG 確保所有可能的捲動作業都能透過執行緒處理，這項機制不只用於顯示清單，甚至適用於更複雜的情況。例如：代表固定位置和固定位置元素的程式碼、被動事件監聽器，以及高品質文字算繪。
GPU 加速
GPU 可大幅加快產生像素及繪製螢幕的速度；在許多情況下，每個像素可以與所有其他像素平行繪製，進而導致速度大幅增加。RenderingNG 的一大要素是 GPU 光柵，可在任何地方繪製。這個架構會在所有平台和所有裝置中使用 GPU，以加快網頁內容的轉譯和動畫速度。這對低階裝置或超高階裝置尤其重要，因為這類裝置的 GPU 通常比裝置的其他部分還多。
擴充性：適合工作的工具
一旦我們擁有穩定性和可擴充性的效能，現在可以以一系列工具為基礎，協助開發人員擴充 HTML、CSS 和 Canvas 的內建部分，以不犧牲效能和可靠性的方式，為開發人員擴充這類元件。
這包括內建加上 JavaScript 公開的 API，適用於回應式設計、漸進式轉譯、流暢度和回應速度，以及執行緒轉譯的進階用途。
下列由 Chromium 主導的開放式網路 API 是由 RenderingNG 所開發，之前被認為是不可行的。
所有這些設備都是根據開放規格開發而成，並與開放式網路合作夥伴 (其他瀏覽器、專家和網頁開發人員的工程師) 攜手合作。在後續的網誌文章中，我們會逐一深入探討這些主題，並說明 RenderingNG 如何做到這點。
- 內容瀏覽權限：可讓網站輕鬆避免畫面外內容轉譯工作，並針對目前未顯示的單頁面應用程式檢視畫面，進行快取轉譯。
- OffscreenCanvas：允許畫布算繪 (2DCanvas API 和 WebGL 皆可) 在自己的執行緒上執行，以獲得可靠的卓越效能。這項專案也是網路的另一項重要里程碑，也是第一個允許 JavaScript (或 WebAssembly!) 從多個執行緒轉譯單一網頁文件的 Web API。
- 容器查詢：允許單一元件根據回應自行版面配置，解除封鎖整個隨插即用元件 (目前為實驗實作項目)。
- 來源隔離：允許網站選擇在 iframe 之間啟用效能隔離功能。
- 非主執行緒繪製工作程式：可讓開發人員利用在合成器執行緒上執行的程式碼，擴充元素的繪製方式。
除了明確的網路 API 外，RenderingNG 也讓我們提供多項極為重要的「自動功能」，造福所有網站：
- 網站隔離：在不同的 CPU 程序中加入跨來源 iframe，以提升安全性和效能隔離效果。
- Vulkan、D3D12 和 Metal：使用比 OpenGL 更有效率的低階 API，
- 更多合成動畫：SVG、背景顏色。
好消息是，RendingNG 無法再推出的其他功能，包括：
- 捲動連結動畫。
- 隱藏、且易於搜尋且可存取的 DOM。
- 共用元素轉換。
- 自訂版面配置。
- 主執行緒外合成；分離執行緒和合成。
RenderingNG 的關鍵專案
以下列出 RenderingNG 中的重要專案。
CompositeAfterPaint
CompositeAfterPaint 異度因樣式、版面配置和繪製而產生的位移，可在不犧牲效能的情況下，大幅提高可靠性和可預測效能、提高總處理量並減少記憶體用量。
| 年 | 進度 |
|---|---|
| 2015 | 出貨顯示清單。 |
| 2017 | 寄送新的撤銷。 |
| 2018 | 船舶屬性樹第 1 部分。 |
| 2019 | 船舶屬性樹第 2 部分。 |
| 2021 | 專案已出貨。 |
LayoutNG
從頭開始重新編寫所有版面配置演算法，大幅提高可靠性和可預測的效能。
進一步瞭解LayoutNG。
| 年 | 進度 |
|---|---|
| 2019 | 運送區塊流。 |
| 2020 | 船具彈性，編輯。 |
| 2021 | 寄送其他東西。 |
BlinkNG
我們重構閃爍引擎，並將其清理為乾淨的管道階段。這可以提供更好的快取效能、更高的可靠性，以及重新輸入或延遲轉譯功能，例如內容瀏覽權限和容器查詢。
隨處可用的 GPU 加速功能
對於大多數內容，GPU 加速功能可平行處理每個像素，因此速度極快。在通常仍具備 GPU 的低階裝置上，也是提升效能的有效方法。
| 年 | 進度 |
|---|---|
| 2014 | Canvas 支援。已於 Android 裝置加入選擇加入的內容。 |
| 2016 | 用 Mac 出貨。 |
| 2017 | 超過 60% 的 Android 網頁瀏覽都在使用 GPU。 |
| 2018 | 透過 Windows、ChromeOS 和 Android Go 出貨。 |
| 2019 | 執行緒 GPU 光柵化。 |
| 2020 | 傳送剩餘的 Android 內容。 |
執行緒捲動、動畫和解碼
長期推動將主執行緒中的所有捲動操作、非版面配置相關的動畫和圖片解碼作業移出主執行緒。更新中。
| 年 | 進度 |
|---|---|
| 2011 | 初步支援執行緒捲動和動畫。 |
| 2015 | 壓縮圖層。 |
| 2016 | 通用溢位捲動。 |
| 2017 | 在合成器執行緒上將圖片解碼。 |
| 2018 | 合成器執行緒上的圖片動畫。 |
| 2020 | 一律複合固定位置。 |
| 2021 | 百分比轉換動畫、SVG 動畫。 |
維茲
Chromium 的集中式光柵和繪圖程序，可提高處理量、最佳化記憶體，並充分運用硬體功能。這對網頁程式開發人員來說還有很多好處，但使用者也能清楚看到，例如解除封鎖網站隔離，以及將轉譯管道與瀏覽器 UI 轉譯分離。
| 年 | 進度 |
|---|---|
| 2018 | OOP-R 已推出 Android、Mac 和 Windows 裝置， |
| 2019 | OOP-D 已出貨。OOP-R 已出貨至任何地方 (畫布除外)。SkiaRenderer 已推出 Linux。 |
| 2020 | SkiaRenderer 內建 Windows 和 Android 系統。Vulkan 搭載 Android。 |
| 2021 | SkiaRenderer 現已推出 Mac (與 ChromeOS 版本)。 |
上方圖表中的字詞定義：
- 失誤
- 獨立程序的顯示合成器。顯示合成活動與 OS 合成器相同。未處理是指在 Viz 程序中進行，而非網頁的轉譯程序或瀏覽器 UI 程序。
- OOP-R
- 獨立程序光柵。光柵正在將顯示清單轉換成像素。未處理是指在 Viz 程序中執行，而非網頁的轉譯程序。
- SkiaRenderer
- 全新的螢幕合成器實作項目，支援在各種不同的基礎 GPU API (例如 Vulkan、D3D12 或 Metal) 上執行。
執行緒和加速畫布算繪
這就是實現 OffscreenCanvas 的專案。
| 年 | 進度 |
|---|---|
| 2018 | 從螢幕外出貨。 |
| 2019 | Ship ImageBitmapRenderingContext。 |
| 2021 | 出貨 OOP-R。 |
VideoNG
VideoNG 的用途為在網站上提供高效率、可靠且高品質的影片播放方式。
| 年 | 進度 |
|---|---|
| 2014 | 引進以 Mojo 為基礎的轉譯架構。 |
| 2015 | 出貨的專案 Butter 和影片重疊，使視訊畫面算繪順暢。 |
| 2016 | 傳送整合式 Android 與桌面解碼及轉譯管道。 |
| 2017 | 已出貨的 HDR 相片和經過色彩校正的影片。 |
| 2018 | 已傳送的 Mojo 影片解碼管道。 |
| 2019 | 出貨的途徑式影片轉譯管道。 |
| 2021 | 已於 ChromeOS 開始支援 4K 受保護內容顯示功能。 |
上方圖表中的字詞定義：
- 摩仔
- Chromium 的新一代 IPC 子系統。
- 途徑
- 這是 Viz 專案設計中的這個概念。
插圖：Una Kravets。