このページは Cloud Translation API によって翻訳されました。

RenderingNG

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

Chris Harrelson

Chris Harrelson です。Blink のレンダリング（HTML と CSS の変換）のエンジニアリングリードです。私は 8 年以上にわたり、ウェブでのレンダリングパフォーマンスの分野に深く関わってきました。個人的な目標は、優れた UX をより速く、簡単かつ安全に提供できるように、できることなら何でも行うことです。新しい最先端の Chromium レンダリングエンジンアーキテクチャを構築するために、当時行った Google の取り組みをご紹介します。これは大変な努力によるものでした

2021 年には、このアーキテクチャの設計、構築、出荷のプロセスの大部分が完了します。今は「RenderingNG」としますRenderingNG は少なくとも 8 年にわたって開発が進められており、多くの Chromium デベロッパーが集まって取り組んでいるものです。高速で滑らかで信頼性が高く、レスポンシブでインタラクティブなウェブコンテンツの次世代の可能性を秘めています。また、デベロッパーが信頼できるすべてのウェブレンダリングエンジンの新しい最低基準を定義するベースラインでもあります。

このブログ投稿はシリーズの第 1 回目です。Google が構築したもの、目的、仕組みについて説明します。最初の投稿では、まず以下のことから始めます。

Google の目標。
「成功のピラミッド」: Google の取り組みの指針となる原則と、その原則の実践例。
RenderingNG によって可能になる特徴と機能
RenderingNG の主なプロジェクトコンポーネントの概要

北極星

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

ブラウザのバグによって機能の信頼性が低下したり、サイトのレンダリングが壊れたりすることを心配する必要はありません。

パフォーマンスの急激な変化があってはなりません。また、不足している組み込みの機能を回避する必要もありません。

正常に動作するはずです。

RenderingNG は、この目標に向けた大きな一歩になると考えています。 RenderingNG の導入前は、レンダリング機能を追加してパフォーマンスを改善できましたが、これらの機能をデベロッパーにとって信頼性のあるものにすることができず、パフォーマンスが大幅に低下しました。現在では、これらの問題の多くを体系的に解消し、これまで実現不可能だと考えられていた高度な機能を解消するアーキテクチャができました。つまり、

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

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

Gecko と Webkit は、これらのブログ投稿で説明したアーキテクチャ機能のほとんどを実装しており、場合によっては Chromium よりも前に実装されています。これは素晴らしいですね！どのブラウザも高速で信頼性が向上すれば、大きな影響があります。しかし、最終的な目標は、すべてのブラウザのベースラインを進化させ、デベロッパーが安心して利用できるようにすることです。

成功のピラミッド

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

ピラミッド、底部に信頼性、中央にパフォーマンス、上部に拡張性のラベル

実際のピラミッドと同様に、各レベルは、その上のレベルの基礎を固く構築します。

信頼性

RenderingNG 機能を使用して、不満を大幅に増やすことなく機能を追加する方法を示すスケッチ

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

スケッチは、特徴の追加、フィードバックの取得、信頼性の向上という循環的な性質を示す

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

信頼性の重要性を実感していただくために私たちはこの 8 年間の大半をこの部分に取り組んできましたまず、システムに関する深い知識を築きました。具体的には、バグレポートから弱点のある箇所を調べて修正し、包括的なテストをブートストラップし、サイトのパフォーマンスニーズと Chromium のパフォーマンスの制限を把握しました。その後、主要な設計パターンとデータ構造を注意深く段階的に設計し、ロールアウトしました。ようやく、レスポンシブデザイン、スケーラビリティ、レンダリングのカスタマイズのための真に次世代のプリミティブを追加する準備が整いました。

時間の経過とともに信頼性、パフォーマンス、拡張性が向上していることを示すスケッチグラフ

その期間中に Chromium で改善された点はないというわけではありません。実は、その逆も真実です。この数年は、Google がリファクタリングを一つずつ進め、改善を段階的に展開する中で、信頼性とパフォーマンスが着実かつ持続的に向上しました。

テストと指標

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

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

ウェブプラットフォームテストは協力して実施されます。たとえば、Chromium のエンジニアが追加した CSS の機能は、WPT テスト全体の約 10% にすぎず、他のブラウザベンダー、独立したコントリビューター、仕様作成者が貢献しています。ウェブの相互運用性を高めるには、人の協力が必要です。

さまざまなエンジンで合格するテスト — wpt.fyi/compat2021 より、コア機能の WPT の合格率を測定

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

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

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

速度、メモリ、電力使用量の面で優れたパフォーマンスを達成することは、RenderingNG の次に最も重要な側面です。Google は、デバイスの安定性を犠牲にすることなく、すべてのウェブサイトとのやり取りをスムーズでレスポンシブにしたいと考えています。

しかし、私たちが求めているのはパフォーマンスだけではありません。スケーラブルなパフォーマンス、つまり、ローエンド、ハイエンドのマシン、OS プラットフォームを問わず確実に動作するアーキテクチャも求めています。私はこれをスケールアップと呼んでいます。これは、ハードウェアデバイスが実現できるすべてのことを活用してスケールダウンすることで、効率を最大化し、必要に応じてシステムへの要求を減らすことです。

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

キャッシュ

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

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

パフォーマンスの分離

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

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

スケッチから、JavaScript が非常に遅い場合でも、RenderingNG を使用するとパフォーマンスが維持されることがわかります。

GPU アクセラレーション

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

スケッチを見ると、RenderingNG を使用してもパフォーマンスはそれほど低下しないことがわかります。

拡張性: ジョブに適したツール

信頼性と拡張性に優れたパフォーマンスが得られたら、HTML、CSS、Canvas の組み込み部分を拡張し、苦労して得たパフォーマンスと信頼性を犠牲にすることなく、デベロッパーが拡張できる多数のツールを利用する準備が整います。

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

Chromium が支持する以下のオープンウェブ API は、RenderingNG によって実現したものであり、以前は実現不可能と考えられていました。

これらはすべて、オープンな仕様と、オープンウェブパートナー（他のブラウザのエンジニア、エキスパート、ウェブデベロッパー）と共同で開発されました。以降のブログ投稿では、それぞれについて詳しく見ていき、RenderingNG によってそれらがどのように実現されるかを説明します。

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

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

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

RenderingNG によってブロックされる今後の追加機能には、次のようなものがあります。

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

以下に、RenderingNG の主なプロジェクトを示します。次回以降のブログ投稿で、それぞれを詳しく見ていきます。

CompositeAfterPaint

スタイル、レイアウト、ペイントから合成を切り離すことで、信頼性と予測可能なパフォーマンスが大幅に向上し、スループットが向上し、パフォーマンスを犠牲にすることなくメモリの使用量を削減できます。2014 年に始まり、今年で終了します。

年	Progress
2015	ディスプレイリストを発送する。
2017	新しい無効化を発行します。
2018 年	船の特性ツリー（パート 1）
2019 年	船の特性ツリー（パート 2）
2021	プロジェクトの出荷を完了しました。

LayoutNG

すべてのレイアウトアルゴリズムを一から書き直したことで、信頼性が大幅に向上し、パフォーマンスの予測可能性が向上しました。2016 年に開始され今年中に終了する予定です

年	Progress
2019 年	ブロックのフロー。
2020 年	柔軟な編集、
2021	その他はすべて発送します。

BlinkNG

Blink レンダリングエンジンのクリーンアップとリファクタリングを行い、明確に分離されたパイプラインフェーズにします。これにより、キャッシュ保存が向上し、信頼性が向上し、コンテンツの可視性やコンテナクエリなどのリエントラントまたは遅延レンダリングが可能になります。この取り組みは 2014 年に始まり、その後も段階的に改善され、現在も続いています。2021 年に完了します。

あらゆる場所での GPU アクセラレーション

すべてのプラットフォームで GPU のラスタライズ、描画、アニメーションを常にロールアウトする長期的な取り組み。 GPU アクセラレーションは、すべてのピクセルを並列処理できるため、ほとんどのコンテンツで速度が大幅に向上します。また、GPU を搭載している傾向があるローエンドデバイスでパフォーマンスを向上させるのにも効果的です。2014 年に始まり、2020 年に完了しました。

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

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

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

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

ビジュアリゼーション

Chromium のラスターおよび描画プロセスを一元化して、スループットを向上させ、メモリを最適化し、ハードウェア機能の最適な利用を実現します。また、サイト分離のブロックを解除する、レンダリングパイプラインをブラウザの UI レンダリングから切り離すなど、ウェブデベロッパーには目立たないものの、ユーザーにとっては目に見えるメリットもあります。2016 年に開始され、2021 年に完了する予定です。

年	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 を可能にした建築要素を配置したプロジェクトです。2015 年に開始し、2021 年に終了する予定です。

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

VideoNG

ウェブ上での効率的で信頼性が高く、高品質な動画再生を提供するための長期的な取り組みです。

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