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

RenderingNG の主なデータ構造

Chris Harrelson

Daniel Cheng

Philip Rogers

Koji Ishi

Ian Kilpatrick

Kyle Charbonneau

それでは、主なデータ構造を見てみましょう。データ構造は、テーブルへの入力と出力です。レンダリングパイプラインです。

データ構造は次のとおりです。

フレームツリーは、ローカルノードとリモートノードで構成され、各ノードがどのウェブレンダリングプロセスと Blink レンダラを確認できます。
イミュータブルフラグメントツリーは、必要があります。
プロパティツリーは変換、クリップ、効果、スクロールの階層を表すありません。これらはパイプライン全体で使用されます。
ディスプレイリストとペイントチャンクは、ラスターおよびレイヤ化アルゴリズムへの入力です。
コンポジタフレーム: サーフェス、レンダリングサーフェス、GPU テクスチャをカプセル化します。 GPU を使用して描画するために使用されるタイルです。

これらのデータ構造について説明する前に、 1 つ目はアーキテクチャレビューですこのの使用例がこのドキュメント全体で使用されています。適用できます。

<!-- Example code -->
<html>
  <div style="overflow: hidden; width: 100px; height: 100px;">
    <iframe style="filter: blur(3px);
      transform: rotateZ(1deg);
      width: 100px; height: 300px"
      id="one" src="foo.com/etc"></iframe>
  </div>
  <iframe style="top:200px;
    transform: scale(1.1) translateX(200px)"
    id="two" src="bar.com"></iframe>
</html>

フレームツリー

Chrome がクロスオリジンフレームのレンダリングを選択することがある親フレームとは別のレンダリングプロセスで行います。

このサンプルコードには、合計 3 つのフレームがあります。

2 つの iframe を含む親フレーム foo.com。

サイト分離により、Chromium はこのウェブページをレンダリングするために 2 つのレンダリングプロセスを使用します。各レンダリングプロセスには、そのウェブページのフレームツリーが独自に表現されています。

2 つのレンダリングプロセスを表す 2 つのフレームツリー。

別のプロセスでレンダリングされたフレームはリモートフレームとして表されます。リモートフレームは、レンダリング時にプレースホルダとして機能するために必要な最小限の情報を保持します。ディメンションなどを指定できますそれ以外の場合、リモートフレームには実際のコンテンツをレンダリングするために必要な情報が含まれません。

これに対して、ローカルフレームは標準規格をパイプラインを実行できますローカルフレームには、回転させるのに必要な情報がすべてそのフレームのデータ（DOM ツリーやスタイルデータ）を基づいています。

レンダリングパイプラインは、ローカルフレームツリーフラグメント: foo.com をメインフレームとする複雑な例を考えてみましょう。

<iframe src="bar.com"></iframe>

次の bar.com サブフレームがあるとします。

<iframe src="foo.com/etc"></iframe>

レンダラは 2 つしかないが、ローカルフレームは 3 つあるツリーフラグメント。foo.com のレンダリングプロセスに 2 つと、 bar.com のレンダリングプロセス:

2 つのレンダリングと 3 つのフレームツリーフラグメントの表現。

ウェブページ用に 1 つのコンポジタフレームを生成するには、 Viz は、それぞれのルートフレームからコンポジタフレームを同時にリクエストします。 3 つのローカルフレームツリー、集約します。コンポジタフレームのセクションもご覧ください。

foo.com メインフレームと foo.com/other-page サブフレーム同じフレームツリーの一部となり、同じプロセスでレンダリングされます。ただし、2 つのフレームは依然として独立してドキュメントライフサイクル異なるローカルフレームツリーフラグメントの一部であるためです。このため、1 回の更新で両方に対して 1 つの合成フレームを生成することは不可能です。レンダリングプロセスに十分な情報がない foo.com/other-page 用に生成されたコンポジタフレームを合成する foo.com メインフレームのコンポジタフレームに直接挿入します。たとえば、プロセス外の bar.com 親フレームが foo.com/other-url iframe の表示に影響することがあります。 CSS を使って iframe を変換したり、DOM 内の他の要素で iframe の一部を隠したりします。

ビジュアルプロパティ更新ウォーターフォール

デバイスのスケールファクタやビューポートのサイズなどの視覚的プロパティがレンダリングされた出力に影響するローカルのフレームツリーフラグメント間で同期する必要があります。各ローカルフレームツリーフラグメントのルートには、ウィジェットオブジェクトが関連付けられています。ビジュアルプロパティの更新は、伝播前にメインフレームのウィジェットに移動される上から下に残るウィジェットに移動します

たとえば、ビューポートのサイズが変更された場合は次のようになります。

前述のテキストで説明したプロセスの図。

この処理は即時には行われません。そのため、複製されたビジュアルプロパティにも同期トークンが含まれています。 Viz コンポジタはこの同期トークンを使用して、すべてのローカルフレームツリーフラグメントを待機する現在の同期トークンを含むコンポジタフレームを送信します。このプロセスにより、異なる視覚的プロパティを持つコンポジタフレームが混在するのを回避できます。

イミュータブルフラグメントツリー

不変のフラグメントツリーは、レンダリングのレイアウトステージの出力です。説明しますページ上のすべての要素の位置とサイズを表します。（変換が適用されません）。

各ツリー内のフラグメントを表し、1 つのフラグメントがレイアウトが必要としてマークされています。

各フラグメントは、DOM 要素の一部を表します。通常、要素ごとにフラグメントは 1 つだけですが、印刷時に複数のページに分割されている場合複数列のコンテキストでは複数の列に分割できます

レイアウト後、各フラグメントは不変になり、再度変更されることはありません。重要な点として、追加の制限もいくつか適用されます。Google がしないこと:

任意の「アップ」を許可する参照です。（子には親へのポインタを設定できません）。
「ふきだし」ツリーの下位レベルに（子は子からの情報のみを読み取り、親からは読み取りません）。

こうした制限により、後続のレイアウトでフラグメントを再利用できるようになります。こうした制限がなければ、ツリー全体を再生成することが多くなり、コストがかかります。

ほとんどのレイアウトは通常、増分アップデートです。たとえば、ユーザーが要素をクリックしたときに UI の一部を更新するウェブアプリ。レイアウトは、画面上で実際に変更された内容に比例して動作するのが理想的です。これは、前のツリーをできるだけ多く再利用することで実現できます。つまり、（通常は）木の背骨を再構築するだけで済みます。

将来的には、この不変の設計により、興味深いことができるようになる可能性がありますたとえば、必要に応じてスレッドの境界を越えて不変のフラグメントツリーを渡すなど、（後続のフェーズを別のスレッドで実行するため）滑らかなレイアウトアニメーションのために複数のツリーを生成する並列投機的レイアウトを実行できますまた、レイアウト自体にもマルチスレッド処理の可能性がもたらされます。

インラインフラグメントアイテム

インラインコンテンツ（主にスタイル設定されたテキスト）では、表現が若干異なります。ボックスとポインタからなるツリー構造ではなくインラインコンテンツをツリーを表すフラットリストで表現します。主な利点は、インラインのフラットリスト表現が高速であり、インラインのデータ構造の検査やクエリにメモリ効率が良くなります。これはウェブレンダリングのパフォーマンスにとって非常に重要ですが、非常に複雑なため高度に最適化しない限りパイプラインで最も遅い部分になりやすいです

フラットリストはインライン書式設定コンテキストそのインラインレイアウトサブツリーを深さ優先検索の順序で検索します。リスト内の各エントリは、（オブジェクト、子孫の数）のタプルです。たとえば、次の DOM について考えてみましょう。

<div style="width: 0;">
  <span style="color: blue; position: relative;">Hi</span> <b>there</b>.
</div>

width プロパティが 0 に設定されているため、行が「Hi」で囲まれます。「there」です。

この状況のインライン書式設定コンテキストをツリーとして表すと、次のようになります。

{
  "Line box": {
    "Box <span>": {
      "Text": "Hi"
    }
  },
  "Line box": {
    "Box <b>": {
      "Text": "There"
    }
  },
  {
    "Text": "."
  }
}

フラットリストは次のようになります。

（折れ線ボックス、2）
（ボックス <span>、1）
（テキスト「こんにちは」、0）
（ラインボックス、3）
（ボックス <b>、1）
（テキスト「そこ」、0）
（テキスト「.」, 0）

このデータ構造には、ユーザー補助 API、などのジオメトリ API をサポートしています。 getClientRects および contenteditable。それぞれに異なる要件があります。これらのコンポーネントは、コンビニエンスカーソルを使用してフラットなデータ構造にアクセスします。

カーソル MoveToNext、MoveToNextLine、CursorForChildren などの API があります。このカーソル表現は、テキストコンテンツにおいて非常に効果的です。これには次のような理由があります。

深度優先検索の反復処理は非常に高速です。キャレットの動きに似ているため、よく使用されます。フラットリストなので深さ優先の検索では配列のオフセットが増加するだけなので、高速なイテレーションとメモリ局所性を実現します
幅優先の検索を提供します。これは、たとえば、背景を描画します
子孫の数を知ることで、次の兄弟姉妹に素早く移動できます。（配列のオフセットをその数値だけ増分します）。

プロパティツリー

DOM は要素（とテキストノード）のツリーであり、CSS ではさまざまな要素を適用できます。

これは次の 4 つの方法で表示されます。

レイアウト: レイアウト制約アルゴリズムへの入力。
ペイント: 要素をペイントしてラスターする方法（ただし、その子孫は対象外です）。
視覚的: DOM サブツリーに適用されるラスター効果や描画効果（変換、フィルタ、クリッピングなど）です。
スクロール: 軸に揃えて角丸含まれるサブツリーのクリッピングとスクロールが自動的に行われます

プロパティツリーは、視覚的効果やスクロール効果が DOM 要素にどのように適用されるかを説明するデータ構造です。このツールは、特定の DOM 要素どうすればよいでしょうか。視覚効果やスクロール効果を適用するには、どのような GPU 操作を使用する必要がありますか？

ウェブでの視覚効果やスクロール効果は非常に複雑で、その魅力は絶大です。プロパティツリーが最も重要なのは、構造と意味を正確に表す単一のデータ構造に統合します。同時に、DOM と CSS のその他の複雑さが取り除かれましたこれにより、より確実な方法で合成とスクロールを行うアルゴリズムを実装できます。具体的には、次のとおりです。

エラーが発生しやすいジオメトリなどの計算 1 か所に一元化できます
プロパティツリーの作成と更新の複雑さ 1 つのレンダリングパイプラインステージに分離されます
プロパティツリーをさまざまなスレッドやプロセスに送信する方が、完全な DOM 状態よりもはるかに簡単で高速です。多数のユースケースに利用できます
ユースケースが多ければ多いほど上に構築されたジオメトリのキャッシュからより多くのメリットを得られます相互に再利用できるためキャッシュです。

プロパティツリーは、RenderingNG で次のようなさまざまな目的で使用されます。

ペイントからの合成とメインスレッドからの合成の分離。
最適な合成 / 描画戦略の決定。
測定 IntersectionObserver ジオメトリ。
画面外要素と GPU テクスチャタイルの処理を回避。
ペイントとラスターを効率的かつ正確に無効化。
測定レイアウトシフトと Core Web Vitals の Largest Contentful Paint

すべてのウェブドキュメントには、transform、clip、effect、scroll という 4 つのプロパティツリーがあります（*）。変換ツリーは、CSS の変換とスクロールを表します。（スクロール変換は 2D 変換行列として表されます）。クリップツリーははみ出すクリップ。効果ツリーは、不透明度、フィルタ、マスク、その他のすべての視覚効果を表します。ブレンドモード、クリップパスなどの他の種類のクリップもサポートしています。スクロールツリーはスクロールやスクロールやスクロールなどのチェーンをまとめるコンポジタスレッドでスクロールを実行するために必要です。プロパティツリーの各ノードは、DOM 要素によって適用されるスクロールまたは視覚効果を表します。複数の効果がある場合は同じ要素の各ツリーに複数のプロパティツリーノードが存在する場合があります。

各ツリーのトポロジは、DOM のスパース表現のようなものです。たとえば、3 つの DOM 要素にオーバーフロークリップがある場合、クリップツリーノードが 3 つ、クリップツリーの構造は、オーバーフロークリップ間の包含ブロック関係を示します。木と木の間にもつながっています。これらのリンクは相対的な DOM 階層を示しています。適用の順序が決まります。たとえば、ある DOM 要素の変換が、フィルタが設定された別の DOM 要素の下にある場合、フィルタの前に変換が適用されます

各 DOM 要素にはプロパティツリー状態があり、 4 タプル（変換、クリップ、効果、スクロール）最も近くにある 1 つの祖先クリップを示すその要素に適用される各種のツリーノードが作成されます。この情報からクリップのリストを正確に把握できるため、非常に便利です。その要素に適用する効果、変換、順序を指定します。これにより、画面上の位置と描画方法がわかります。

注:（*）スクロールは内部のサブツリーにのみ適用されるため、ツリーは 4 つあります。要素がスクローラーと一緒にスクロールされる場合、その要素はスクローラーに包含されます。、position:absolute、position: fixed スクロール要素は祖先のスクロール要素をエスケープしスクロール要素が、それを含むブロックチェーンにない場合（DOM 要素の包含ブロックチェーンは、その包含ブロックと、その包含ブロックの包含ブロックというように、ルート要素まで続きます）。再帰的）です。ただし、その他のすべての視覚効果は DOM サブツリー全体に適用されます。この不一致によりプロパティツリーのクリッピングとスクロールのトポロジ視覚効果とはまったく異なるものですそのため、ほとんどの視覚効果では、すべての子孫に対して包含ブロックが作成されます。（例）。プロパティツリーの完全な構造は非常に複雑です。長いコードのコメントとこちらをご覧ください。

例

（出典）

<html>
  <div style="overflow: scroll; width: 100px; height: 100px;">
    <iframe style="filter: blur(3px);
      transform: rotateZ(1deg);
      width: 100px; height: 300px"
  id="one" srcdoc="iframe one"></iframe>
  </div>
  <iframe style="top:200px;
      transform: scale(1.1) translateX(200px)" id=two
      srcdoc="iframe two"></iframe>
</html>

前述の例（冒頭部分の例とは少し異なる例）では、生成されるプロパティツリーの主な要素は次のとおりです。

プロパティツリーのさまざまな要素の例。

リストを表示してチャンクをペイントする

表示アイテムには、下位レベルの描画コマンドが含まれます（こちら）ラスタライズ可能な Skia. 表示アイテムは通常、枠線や背景の描画など、いくつかの描画コマンドのみを使用するシンプルなものです。ペイントツリーウォークは、CSS の描画順序に従って、レイアウトツリーと関連フラグメントを反復処理します。アイテムのリストを作成します。

例:

「Hello World」と書かれた青いボックス緑の長方形の中に表示されます

<div id="green" style="background:green; width:80px;">
    Hello world
</div>
<div id="blue" style="width:100px;
  height:100px; background:blue;
  position:absolute;
  top:0; left:0; z-index:-1;">
</div>

この HTML と CSS を使用すると、次のようなディスプレイリストが生成されます。各セルは 1 つの表示項目です。

ビューの背景	`#blue`のバックグラウンド	`#green`のバックグラウンド	`#green` インラインテキスト
`drawRect`（サイズ 800x600、色: White）	位置 0,0、サイズ 100x100、色: blue の `drawRect`。	`drawRect`（位置 8.8、サイズ 80x18、色: 緑色）	位置 8、8、テキスト「Hello world」の `drawTextBlob`。

アイテムリストは逆から上に並べられます。上の例では、DOM 順で緑の div が青い div の前にあり、 CSS の描画順序により、負の Z-Index の青い div が描画される必要がありますステップ 3 の緑色の div 要素（ステップ 4.1）。表示するアイテムは、CSS のペイント順序仕様のアトミックなステップにほぼ対応しています。 1 つの DOM 要素から複数の表示オプションが作成されることもありますが、 #green で、背景用のディスプレイアイテムとインラインテキスト用のもう一つのディスプレイアイテムをどのように設定するかなどです。この粒度は、CSS のペイント順序仕様の完全な複雑さを表すために重要です。負のマージンによって作成されたインターリーブなど:

グレーのボックスが部分的に重なっている緑色の長方形と「Hello world」というテキスト。

<div id="green" style="background:green; width:80px;">
    Hello world
</div>
<div id="gray" style="width:35px; height:20px;
  background:gray;margin-top:-10px;"></div>

これにより、次のディスプレイリストが生成されます。各セルは 1 つのアイテムです。

ビューの背景	`#green`のバックグラウンド	`#gray`のバックグラウンド	`#green` インラインテキスト
`drawRect`（サイズ 800x600、色: White）	`drawRect`（位置 8.8、サイズ 80x18、色: 緑色）	サイズ 35x20、位置 8、16、色: `drawRect`。	位置 8、8、テキスト「Hello world」の `drawTextBlob`。

ディスプレイアイテムリストが保存され、以降の更新で再利用されます。ペイントツリーウォーク中にレイアウトオブジェクトが変更されていない場合、前のリストからコピーされます。 CSS のペイント順序仕様のプロパティに依存する最適化もあります。スタックコンテキストはアトミックに描画されます。スタックコンテキスト内でレイアウトオブジェクトが変更されていない場合、ペイントツリーウォークでスタックコンテキストがスキップされる前のリストから表示アイテムのシーケンス全体をコピーします。

ペイントツリーウォーク中は現在のプロパティツリーの状態が維持されるディスプレイアイテムのリストは「チャンク」にグループ化され同じプロパティツリー状態を共有している一部の表示項目が除外されます。これを次の例に示します。

ピンクのボックスとオレンジ色のボックスが傾いている。

<div id="scroll" style="background:pink; width:100px;
   height:100px; overflow:scroll;
   position:absolute; top:0; left:0;">
    Hello world
    <div id="orange" style="width:75px; height:200px;
      background:orange; transform:rotateZ(25deg);">
        I'm falling
    </div>
</div>

これにより、次のディスプレイリストが生成されます。各セルは 1 つのアイテムです。

ビューの背景	`#scroll`のバックグラウンド	`#scroll` インラインテキスト	`#orange`のバックグラウンド	`#orange` インラインテキスト
`drawRect`（サイズ 800x600、色: White）	`drawRect`（位置 0、0、サイズ 100x100、色: ピンク）	位置が 0、0、テキストが「Hello World」の `drawTextBlob`。	`drawRect`（位置 0,0、サイズ 75×200、色: オレンジ色）	位置 0,0 とテキスト「I'mfalling」の`drawTextBlob`。

この場合、変換プロパティツリーとペイントチャンクは次のようになります（簡略化のために簡略化しています）。

前の表の画像。チャンク 1 の最初の 2 つのセル、チャンク 2 の最初の 2 つのセル、チャンク 3 の最後の 2 つのセル。

ペイントチャンクの順序付きリスト、プロパティツリーの状態を示すグループです。レンダリングパイプラインの階層化ステップへの入力です。ペイントチャンクのリスト全体を 1 つの合成レイヤにマージして、一緒にラスタライズできます。しかしこの方法では、ユーザーがスクロールするたびに負荷の高いラスタライズが必要になります。塗料チャンクごとに合成レイヤを作成できるすべての再ラスタライズを回避するために個別にラスタライズされますが、GPU メモリがすぐに使い果たされてしまいます。階層化のステップでは、GPU メモリと、状況が変化した場合のコスト削減との間でトレードオフを行う必要があります。推奨される一般的なアプローチは、デフォルトでチャンクをマージすることです。コンポジタスレッドで変化することが予想されるプロパティツリー状態を持つペイントチャンクをマージしないこと。コンポジタスレッドのスクロールやコンポジタスレッドの変換アニメーションなどで使用する必要があります。

上記の例では、理想的には、次の 2 つの合成レイヤを生成する必要があります。

描画コマンドを含む 800x600 の合成レイヤ: <ph type="x-smartling-placeholder">
1. drawRect（サイズ 800x600、色: White）
2. drawRect（位置 0、0、サイズ 100×100、色: ピンク）
描画コマンドを含む 144x224 の合成レイヤ: <ph type="x-smartling-placeholder">
1. 位置が 0、0、テキストが「Hello World」の drawTextBlob
2. 0,18 相当を翻訳
3. rotateZ(25deg)
4. drawRect（位置 0,0、サイズ 75×200、色: オレンジ色）
5. 位置 0,0 とテキスト「I'mfalling」のdrawTextBlob

ユーザーが #scroll をスクロールすると、 2 番目の合成レイヤは移動されますが、ラスタライズは必要ありません。

例: 説明しましたが、 6 つのペイントチャンクがありますプロパティツリーの状態（変換、クリップ、効果、スクロール）と合わせて、以下のようになります。

ドキュメントの背景: ドキュメントのスクロール、ドキュメントクリップ、ルート、ドキュメントのスクロール。
div の水平方向、垂直方向、スクロールの角（3 つの個別のペイントチャンク）: ドキュメントのスクロール、ドキュメントクリップ、#one ぼかし、ドキュメントのスクロール。
iframe #one: #one 回転、オーバーフロースクロールクリップ、#one ぼかし、div スクロール。
iframe #two: #two 縮尺、ドキュメントクリップ、ルート、ドキュメントのスクロール。

コンポジタフレーム: サーフェス、レンダリングサーフェス、GPU テクスチャタイル

ブラウザとレンダリングプロセスはコンテンツのラスタライズを管理します。コンポジタフレームを Viz プロセスに送信して画面に表示します。コンポジターフレームはラスター化されたコンテンツをつなぎ合わせる方法を表す GPU を使って効率的に描画します。

タイル

理論上レンダリングプロセスまたはブラウザプロセスコンポジタでピクセルがラスタライズされることがあるフルサイズの 1 つのテクスチャに変換し、そのテクスチャを Viz に送信します。これを表示するには、ディスプレイコンポジタでピクセルをコピーするだけで済みます。その単一のテクスチャからフレームバッファの適切な位置に読み込みます。（画面など）。ただし、そのコンポジターが 1 ピクセルでビューポート全体をラスタライズし、新しいテクスチャを Viz に送信する必要があります。

代わりに、ビューポートはタイルに分割されます。個別の GPU テクスチャタイルが、ビューポートの一部に対してラスタライズされたピクセルを使用して各タイルをバックアップします。レンダラは個々のタイルや既存のタイルの画面上の位置を変更するだけですたとえばウェブサイトをスクロールするときは既存のタイルの位置が上がったりページの下流のコンテンツでは新しいタイルをラスタライズする必要があります。

4 枚のタイル。 — この画像は、晴れた日の 4 つのタイルを表しています。スクロールが発生すると、5 番目のタイルが表示され始めます。タイルの 1 つが 1 つの色（スカイブルー）になっている場合、上部に動画と iframe があります。

クアッドとサーフェス

GPU テクスチャタイルは、特別な種類のクワッドです。テクスチャのあるカテゴリを表す華やかな名前です。クワッドは入力テクスチャを識別し、そのテクスチャを変換して視覚効果を適用する方法を示します。たとえば、通常のコンテンツタイルには、タイルグリッド内の x、y 位置を示す変換があります。

GPU テクスチャタイル。

これらのラスタライズされたタイルは、クワッドのリストであるレンダリングパスにラップされます。レンダリングパスにはピクセル情報は含まれません。望ましいピクセル出力を生成するために、各クワッドをどこで、どのように描画するかが指示されます。 GPU テクスチャタイルごとに描画クワッドがあります。ディスプレイコンポジタはクワッドのリストを反復処理するだけです。指定された視覚効果で絵を描き、レンダリングパスに必要なピクセル出力を生成します。レンダリングパス用の描画クワッドの合成は、GPU で効率的に実行できます。これは、許可される視覚効果が、GPU 機能に直接マッピングされる視覚効果であることを慎重に選択しているためです。

ラスタライズされたタイル以外にも、描画クワッドには種類があります。たとえば、テクスチャにまったく裏付けられていない単色描画クワッドもあります。動画やキャンバスなどのタイル以外のテクスチャの場合は、テクスチャ描画クワッドを使用します。

コンポジタフレームに別のコンポジタフレームを埋め込むこともできます。たとえば、ブラウザコンポジタはブラウザの UI を含むコンポジタフレームを生成します。レンダリングコンポジタのコンテンツが埋め込まれる空の長方形が作成されます。別の例として、サイト分離 iframe があります。この埋め込みは、サーフェスを使用して行われます。

コンポジタがコンポジタフレームを送信すると、これはサーフェス ID と呼ばれ、他のコンポジタフレームが参照によって埋め込めるようにします。特定のサーフェス ID で送信された最新のコンポジタフレームが Viz によって保存されます。その後、別のコンポジタフレームが Surface Draw クワッドを介してそれを参照できます。 Viz は何を描くべきか把握しています。（サーフェス描画クワッドにはサーフェス ID のみが含まれ、テクスチャは含まれません）。

中間レンダリングパス

多くのフィルタや高度なブレンドモードなど、一部の視覚効果は、では、2 つ以上のクワッドを中間テクスチャに描画する必要があります。次に、中間テクスチャを GPU 上の宛先バッファ（または別の中間テクスチャ）に描画します。ビジュアルエフェクトを同時に適用できます。これを可能にするために、コンポジタフレームには実際にレンダリングパスのリストが含まれています。ルートレンダリングパスは常に存在します。最後に描画され、そのデスティネーションがフレームバッファに対応します。他にもあるかもしれません

複数のレンダリングパスが存在する可能性がある。「レンダリングパス」と指定します。各パスは、GPU で複数の「パス」で順番に実行されなければなりません。これに対して 1 パスは 1 つの超並列 GPU 計算で完了できます。

集計

複数のコンポジタフレームを Viz に送信し、一緒に画面に描画する必要がありますこれを実現するのが、集約フェーズによって行われます。集約コンポジタフレームを作成します。集約では、サーフェス描画クワッドが指定したコンポジタフレームで置き換えられます。また、不要な中間テクスチャや画面外のコンテンツを最適化できる機会でもあります。たとえば、多くの場合、サイト分離 iframe のコンポジターフレームは独自の中間テクスチャは必要ありません適切な描画クワッドを介してフレームバッファに直接描画できます。集計フェーズでは個々のレンダリングコンポジタではアクセスできないグローバルな知識に基づいて適用します。

例

ここに示されているのは、最初の例を表すコンポジターフレームです。説明します。

foo.com/index.html サーフェス: id=0 <ph type="x-smartling-placeholder">
- レンダリングパス 0: 出力に描画します。
  - レンダリングパスの描画クワッド: 3 ピクセルのぼかしで描画し、レンダリングパス 0 にクリップします。
    - レンダリングパス 1: <ph type="x-smartling-placeholder">
      - #one iframe のタイルコンテンツのクワッドを描画し、それぞれに x 位置と y 位置を指定します。
  - サーフェス描画クワッド: ID 2、スケールと平行移動変換で描画。
ブラウザ UI サーフェス: ID=1 <ph type="x-smartling-placeholder">
- レンダリングパス 0: 出力に描画します。
  - ブラウザ UI のクワッドを描画する（タイル表示も可能）
bar.com/index.html サーフェス: ID=2 <ph type="x-smartling-placeholder">
- レンダリングパス 0: 出力に描画します。
  - #two iframe のコンテンツにクワッドを描画し、それぞれに x 位置と y 位置を指定します。

イラスト: Una Kravets。

RenderingNG の主なデータ構造

フレームツリー

ビジュアル プロパティ更新ウォーターフォール

イミュータブル フラグメント ツリー

インライン フラグメント アイテム

プロパティ ツリー

例