RenderingNG

次世代のウェブ コンテンツに対応

Chris Harrelson

RenderingNG は次世代のレンダリング アーキテクチャで、以前をはるかに上回る性能を備えています。RenderingNG は 8 年以上にわたって構築され、多くの熱心な Chromium デベロッパーが共同で開発したものです。高速で滑らかで、信頼性が高く、レスポンシブでインタラクティブなウェブ コンテンツの可能性を引き出します。

RenderingNG

ここでは、Google が構築したもの、構築した理由、仕組みについて説明します。

北極星の目標

RenderingNG の推進力となる目標は、ブラウザ エンジンの実装とそのレンダリング API の豊富さが、ウェブ上の UX を制限する要因にならないようにすることです。

ブラウザのバグが原因で機能の信頼性が低下したり、サイトのレンダリングが壊れたりする心配はありません。

不思議なパフォーマンスの低下が発生しないはずです。また、不足している組み込み機能を回避する必要はありません。

うまくいくはずです。

RenderingNG は、この目標に向けた大きな一歩です。RenderingNG が導入される前は、レンダリング機能を追加してパフォーマンスを向上させることはできましたが、そのような機能をデベロッパーにとって信頼性のあるものにするのに苦労し、パフォーマンスの壁が数多くありました。現在のアーキテクチャでは、こうした問題の多くを体系的に解決し、以前は実現不可能と考えられていた高度な機能も排除しています。つまり、

• さまざまなプラットフォーム、デバイス、オペレーティング システムの組み合わせに対応した堅牢なコア機能を搭載している。
• 予測可能で信頼性の高いパフォーマンスを実現。
• ハードウェア機能（コア、GPU、画面解像度、リフレッシュ レート、低レベルラスター API）の使用を最大化します。
• 可視コンテンツの表示に必要な作業のみを行います。
• 一般的なビジュアル デザイン、アニメーション、インタラクション デザイン パターンのサポートが組み込まれています。
• レンダリング コストを簡単に管理できるデベロッパー向け API を提供します。
• デベロッパー アドインのレンダリング パイプライン拡張ポイントを提供します。
• HTML、CSS、2D キャンバス、3D キャンバス、画像、動画、フォントなど、すべてのコンテンツを最適化します。

他のブラウザ レンダリング エンジンとの比較

Gecko と Webkit も、これらのブログ投稿で紹介したのと同じアーキテクチャ機能のほとんどを実装しており、場合によっては Chromium より前に追加されていることもあります。

ブラウザの速度と信頼性が向上したことは、称賛のきっかけとなり、大きな影響をもたらします。最終的な目標は、すべてのブラウザのベースラインを引き上げ、デベロッパーがそのベースラインを活用できるようにすることです。

成功のピラミッド

私の信念は、成功はまず信頼性、次にスケーラブルなパフォーマンス、そして最終的には拡張性を達成した結果であるということです。

実際のピラミッドと同様に、各レベルは上のレベルの強固な基盤となります。

信頼性

豊かで複雑なユーザー エクスペリエンスを実現するには、まず堅牢なプラットフォームが必要です。コア機能と基礎は正しく機能し、時間が経過しても機能し続ける必要があります。また、これらの機能が適切に構成され、奇妙なエッジケースの動作やバグがないことも重要です。

このため、信頼性が RenderingNG の最も重要な要素となっています。信頼性は 優れたテスト、品質フィードバックループ 指標、ソフトウェア設計パターンから得られます

信頼性がどれほど重要であるかを説明するために、Google は過去 8 年の大部分をこの部分だけに費やしました。まず、システムに関する深い知識を築き上げました。バグレポートから弱点のある部分を学習して修正し、包括的なテストをブートストラップし、サイトのパフォーマンス ニーズと Chromium のパフォーマンスの限界を把握します。その後、重要な設計パターンとデータ構造を慎重に設計し、段階的に設計し、ロールアウトしました。そしてついに、レスポンシブ デザイン、スケーラビリティ、レンダリングのカスタマイズのために真の次世代プリミティブを追加する準備が整いました。

だからと言って、これまで Chromium で改善が何もなかったわけではなく、実際には、その逆も同様です。各改善を段階的にリファクタリングし、ロールアウトするなかで、信頼性とパフォーマンスは着実かつ持続的に向上しました。

テストと指標

過去 8 年間で、数万の単体テスト、パフォーマンス テスト、統合テストが追加されています。さらに、ローカルテスト、パフォーマンス ベンチマーク、実際のユーザーおよびデバイスを使用した実際の環境での Chromium のレンダリング動作をさまざまな側面から測定する包括的な指標も開発しました。

しかし、RenderingNG（あるいは他のブラウザのレンダリング エンジン）がどれほど優れていても、多くのバグやブラウザ間で動作の違いがある場合は、ウェブ向けの開発は容易ではありません。これに対処するために、Google はウェブ プラットフォーム テストを最大限に活用しています。これらのテストではそれぞれ、すべてのブラウザが合格を目指すウェブ プラットフォームの使用パターンを検証します。また、指標を注意深くモニタリングして、時間の経過とともにより多くのテストに合格し、コアの互換性を高めているようにしています。

ウェブ プラットフォーム テストは共同作業です。たとえば、Chromium のエンジニアは、CSS の機能に対する WPT テスト全体の約 10% しか追加していません。残りは他のブラウザ ベンダー、独立系コントリビューター、仕様作成者によるものです。相互運用可能なウェブを世に広めるには、多くの人々が協力する必要があります。

wpt.fyi/compat2021 より、コア機能の WPT の合格率の測定

優れたソフトウェア設計パターン

コードが理解しやすく、バグの可能性を最小限に抑えるように設計されていると、高品質のソフトウェアを確実に提供できるようになります。RenderingNG のソフトウェア設計については、今後のブログ投稿でさらに多くお話しする予定です。

スケーラブルなパフォーマンス

速度、メモリ、消費電力の面で優れたパフォーマンスを達成することは、RenderingNG の次に重要な側面です。Google は、デバイスの安定性を犠牲にすることなく、すべてのウェブサイトとのやり取りがスムーズで応答性の高いものにする必要があります。

ただし、パフォーマンスだけでなく、スケーラブルなパフォーマンス、つまりローエンド マシンとハイエンド マシン、および OS プラットフォームで確実に適切に機能するアーキテクチャを求めています。これをスケールアップと呼び、ハードウェア デバイスが実現できるすべての機能を利用することと、スケールダウンによって、効率を最大化し、必要に応じてシステムの需要を低減することを言います。

これを実現するには、キャッシュ、パフォーマンスの分離、GPU ハードウェア アクセラレーションを最大限活用する必要がありました。順番に見ていきましょう具体的に説明するために、ウェブページ上で非常に重要な 1 つの操作であるスクロールのパフォーマンスに、それぞれのシグナルがどのように貢献するかを考えてみましょう。

キャッシュ

ウェブなどの動的でインタラクティブな UI プラットフォームにおいて、パフォーマンスを劇的に改善する最も重要な手段はキャッシュです。ブラウザでのキャッシュ保存として最も一般的な方法は HTTP キャッシュですが、レンダリングにも多数のキャッシュがあります。スクロールで最も重要なキャッシュは、キャッシュに保存された GPU テクスチャとディスプレイ リストです。これにより、バッテリーの消耗を最小限に抑えながら、さまざまなデバイスで適切に動作しながら、スクロールが非常に高速になります。

キャッシュ保存はスクロールのバッテリー駆動時間とアニメーション フレームレートの向上に役立ちますが、さらに重要な点は、パフォーマンスがメインスレッドから分離されなくなることです。

パフォーマンスの分離

最新のデスクトップ パソコンでは、バックグラウンド アプリケーションによって作業中のアプリケーションが遅くなることを心配する必要はありません。これは、プリエンプティブ マルチタスクによるものです。プリエンプティブ マルチタスクは、パフォーマンスの分離の一種であり、独立したタスクが互いに速度を低下させないようにします。

ウェブにおけるパフォーマンスの分離に最適な例はスクロールです。JavaScript やレイアウト スレッドに依存しない別のスレッドで実行されるため、JavaScript が遅いウェブサイトでも、スクロールは非常にスムーズに行えます。Google は RenderingNG に多大な労力を費やし、単なるディスプレイ リストだけでなく、より複雑な状況にも対応できるキャッシュを通じて、可能なスクロールがすべてスレッド化されるようにしています。たとえば、固定位置と固定位置の要素、パッシブ イベント リスナー、高品質のテキスト レンダリングを表すコードがあります。

GPU アクセラレーション

GPU を使用すると、ピクセルの生成と画面への描画が大幅に高速化されます。多くの場合、すべてのピクセルを 1 つのピクセルと平行に描画できるため、速度が大幅に向上します。RenderingNG の重要な要素は、GPU ラスターとあらゆる場所での描画です。あらゆるプラットフォームとデバイスで GPU を使用して、ウェブ コンテンツのレンダリングとアニメーション化を高速に処理します。 これは、デバイスの他の部分よりもはるかに高性能な GPU を搭載しているローエンド デバイスや非常にハイエンドのデバイスで特に重要です。

拡張性: 業務に適したツール

信頼性と拡張性に優れたパフォーマンスを確保できたら、デベロッパーが HTML、CSS、描画キャンバスの組み込み部分を拡張し、苦労して勝ち取ったパフォーマンスと信頼性を犠牲にしない方法で、デベロッパーがさまざまなツールを構築する準備が整いました。

これには、レスポンシブ デザイン、プログレッシブ レンダリング、スムーズさと応答性、スレッド レンダリングの高度なユースケース向けの組み込み API と JavaScript 公開 API が含まれます。

Chromium で支持されている次のオープンウェブ API は、RenderingNG によって可能になり、以前は実現不可能とみなされていました。

これらはすべて、オープンな仕様に沿って開発されており、他のブラウザのエンジニア、エキスパート、ウェブ デベロッパーといったオープン ウェブ パートナーとのコラボレーションも行われています。以降のブログ投稿では、それぞれについて詳しく説明し、RenderingNG によって実現される仕組みについて説明します。

• コンテンツの可視性: サイトでオフスクリーン コンテンツのレンダリング作業を簡単に回避でき、現在表示されていないシングルページ アプリケーション ビューのキャッシュ レンダリングが可能になります。
• OffscreenCanvas: キャンバス レンダリング（2D キャンバス API と WebGL の両方）を独自のスレッドで実行し、優れたパフォーマンスを確実に維持できます。このプロジェクトは、ウェブの大きな節目でもあります。JavaScript（または WebAssembly）が複数のスレッドから 1 つのウェブページ ドキュメントをレンダリングできるようにする初めてのウェブ API です。
• コンテナクエリ: 単一のコンポーネントをレスポンシブにレイアウトできるため、プラグアンドプレイ コンポーネント全体（現在は試験運用版の実装）をブロック解除できます。
• オリジンの分離: サイトで iframe 間のパフォーマンスをより細かく分離できます。
• オフメインスレッドのペイント ワークレット: デベロッパーはコンポジタ スレッドで実行されるコードを使用して、要素のペイント方法を拡張できます。

明示的なウェブ API に加え、RenderingNG により、すべてのサイトにメリットをもたらす非常に重要な「自動機能」をいくつか搭載できるようになりました。

• サイト分離: クロスオリジンの iframe を別々の CPU プロセスに配置し、セキュリティとパフォーマンスの分離を強化します。
• Vulkan、D3D12、Metal: OpenGL よりも効率的に GPU を使用する低レベル API を利用します。
• より合成されたアニメーション: SVG、背景色。

RenderingNG で実現できる、今後追加される新機能には次のようなものがあります。

• スクロール リンク アニメーション。
• 非表示だが検索可能でアクセス可能な DOM。
• 共有要素遷移。
• カスタム レイアウト。
• オフメインスレッドでの合成、スレッド化と合成の分離。

RenderingNG を構成する主なプロジェクト

以下に、RenderingNG の主なプロジェクトの一覧を示します。

CompositeAfterPaint

CompositeAfterPaint は、スタイル、レイアウト、ペイントから合成することで、信頼性と予測可能なパフォーマンスを大幅に向上させ、スループットを向上させ、パフォーマンスを犠牲にすることなくメモリの使用量を削減します。

年	Progress
2015	ディスプレイ リストを送信する。
2017	新しい無効化を出荷する。
2018	船舶資産ツリー、パート 1.
2019	船舶資産ツリー、パート 2.
2021	プロジェクトの発送が完了しました。

LayoutNG

信頼性が大幅に向上し、パフォーマンスの予測可能性を高めるために、すべてのレイアウト アルゴリズムを根本から書き換えました。

LayoutNG の詳細を確認する。

年	Progress
2019	出荷ブロック フロー。
2020	フレキシブルな宇宙船の編集、編集。
2021	それ以外はすべて発送する。

BlinkNG

Blink レンダリング エンジンをリファクタリングし、明確に分離されたパイプライン フェーズにクリーンアップしました。これにより、キャッシュ保存が改善され、信頼性が向上し、コンテンツの表示設定やコンテナクエリなど、再入可能または遅延レンダリングの機能を利用できるようになります。

どこでも GPU アクセラレーション

すべてのピクセルを並列処理できるため、ほとんどのコンテンツで GPU アクセラレーションを使用すると、処理速度が大幅に向上します。また、GPU を搭載していることが多いローエンド デバイスでパフォーマンスを向上させるのにも効果的な方法です。

年	Progress
2014	Canvas のサポート。Android のオプトイン コンテンツで発送されます。
2016	Mac でリリースします。
2017	Android のページビューの 60% 以上に GPU が使用されています。
2018	Windows、ChromeOS、Android Go で出荷。
2019	スレッド化された GPU のラスタライズ。
2020	残りの Android コンテンツを公開する。

スレッド形式のスクロール、アニメーション、デコード

スクロール、レイアウトを誘導しないアニメーション、画像のデコードをすべてメインスレッドから移すための長期的な取り組み。現在も進行中です。

年	Progress
2011	スレッド スクロールとアニメーションを最初にサポートしました。
2015	レイヤの圧縮。
2016	ユニバーサル オーバーフローのスクロール。
2017	画像はコンポジタ スレッドでデコードされます。
2018	コンポジタ スレッドでの画像アニメーション。
2020	常に固定位置を合成します。
2021	割合変換アニメーション、SVG アニメーション。

ビジュアリゼーション

スループットの向上、メモリの最適化、ハードウェア機能の最適な使用を可能にする、Chromium の一元化されたラスター プロセスと描画プロセス。他にも、ウェブ デベロッパーにはあまり見えませんが、ユーザーにはよく見えるという利点があります。たとえば、サイト分離の解除や、ブラウザ UI レンダリングからレンダリング パイプラインを分離できます。

年	Progress
2018	OOP-R は Android、Mac、Windows に搭載されています。
2019	OOP-D を発送しました。OOP-R はすべての地域（Canvas を除く）に発送されます。SkiaRenderer は Linux に搭載されています。
2020	SkiaRenderer は Windows と Android に搭載されています。Vulkan は Android に搭載されています。
2021	SkiaRenderer が Mac にリリースされました（まもなく ChromeOS にも搭載されます）。

上のグラフの用語の定義:

OOP-D

プロセス外のディスプレイ コンポジタ。ディスプレイの合成は、OS コンポジタと同じ種類のアクティビティです。プロセス外とは、ウェブページのレンダリング プロセスやブラウザ UI プロセスではなく、Viz プロセス内で実行することを意味します。

OOP-R

プロセス外のラスター。ラスターはディスプレイ リストをピクセルに変換します。 プロセス外とは、ウェブページのレンダリング プロセスではなく、Viz プロセス内で実行することを意味します。

SkiaRenderer

Vulkan、D3D12、Metal など、基盤となるさまざまな GPU API での実行をサポートできる新しいディスプレイ コンポジタ実装。

キャンバスのスレッド表示と高速化

これが OffscreenCanvas を可能にしたプロジェクトです。

年	Progress
2018	OffscreenCanvas を送付する。
2019	ImageBitmapRenderingContext を送信します。
2021	OOP-R を発送します。

VideoNG

VideoNG は、ウェブ上で効率的かつ信頼性の高い高品質の動画再生を実現するための長期的な取り組みです。

年	Progress
2014	Mojo ベースのレンダリング フレームワークを導入しました。
2015	スムーズな動画レンダリングのための Project Butter と動画オーバーレイを出荷しました。
2016	Android およびデスクトップのデコードとレンダリングの統合パイプラインを搭載。
2017	HDR と色補正された動画レンダリングを出荷。
2018	Mojo ベースの動画デコード パイプラインを出荷。
2019	サーフェス ベースの動画レンダリング パイプラインを出荷。
2021	ChromeOS で 4K 保護されたコンテンツ レンダリングをサポートしました。

上のグラフの用語の定義:

モジョ

Chromium 用の次世代 IPC サブシステム。

画面

Viz プロジェクト設計の一部であるコンセプト。

---

イラスト: Una Kravets