Firefox Quantumのリリースまでの残り時間が少なくなりました。 Servoから借りた超高速CSSエンジンを含む、多くのパフォーマンスの改善がもたらされます。



しかし、Servoテクノロジーにはもう1つの大きな部分があり、Firefox Quantumにはまだ含まれていませんが、まもなく登場します。 これはQuantum Renderプロジェクトの一部であるWebRenderです。







WebRenderは、並外れた速度で知られています。 しかし、主なタスクはレンダリングの速度を上げることではなく、レンダリングをよりスムーズにすることです。



WebRenderを開発する際、ディスプレイのサイズやアニメーションのサイズに関係なく、すべてのアプリケーションが60フレーム/秒（FPS）以上で実行されるように目標を設定します。 そしてそれは働いた。 WebRenderの起動時に 、Chromeで15 FPSでパフするページまたは現在のFirefox で60 FPSで飛ぶページ。



WebRenderはどのようにこれを行いますか？ これにより、レンダリングエンジンの原理が根本的に変わり、3Dゲームエンジンのようになります。



これが何を意味するかを理解しましょう。 しかし、最初に...

レンダラーは何をしますか？

Styloの記事で 、ブラウザーがHTMLとCSSの解析から画面上のピクセルに移動する方法と、ほとんどのブラウザーが5つのステップでこれを行う方法について説明しました。



これらの5つのステップは2つの部分に分けることができます。 それらの最初は、本質的に、計画を立てることです。 計画を立てるために、ブラウザは、ビューポートのサイズなどの情報を考慮してHTMLとCSSを解析し、各要素の幅、高さ、色などを正確に把握します。 最終結果は、「フレームツリー」または「レンダーツリー」と呼ばれるものです。



2番目の部分（レンダリングとレイアウト）では、レンダラーが動作します。 彼はこの計画を採用し、画面上のピクセルに変換します。







しかし、ブラウザはこれを一度だけ行うのに十分ではありません。 彼は同じWebページに対して何度も操作を繰り返す必要があります。 スイッチでdivが開くなど、ページ上で何かが変更されるたびに、ブラウザーはすべてのステップを何度も繰り返さなければなりません。







ページ上で何も変更されていなくても（たとえば、単にスクロールしたりテキストを選択したり）、ブラウザは引き続きレンダリング操作を実行して画面に新しいピクセルを描画する必要があります。







スクロールとアニメーションをスムーズにするには、毎秒60フレームで更新する必要があります。



このフレーズを聞いたことがあるかもしれません-1秒あたりのフレーム数（FPS）-意味がわからない。 私はそれらをフリップブックとして提示します。 これは、静止画を含む本のようなもので、すばやくスクロールしてアニメーションの錯覚を作成できます。



このようなフリップブックのアニメーションを滑らかに見せるためには、毎秒60ページを表示する必要があります。







フリップブックのページはグラフ用紙でできています。 多数の小さな正方形があり、各正方形には1色しか含めることができません。



レンダラーのタスクは、グラフ用紙の四角を塗りつぶすことです。 それらがすべていっぱいになると、フレームのレンダリングが終了します。



もちろん、コンピュータには実際のグラフ用紙はありません。 代わりに、コンピューターにはフレームバッファーと呼ばれるメモリ領域があります。 フレームバッファ内の各メモリアドレスは、グラフ用紙上の正方形のようなものです...画面上のピクセルに対応しています。 ブラウザーは、各セルにRGBA値（赤、緑、青、およびアルファ）に一致する数値を入力します。







画面を更新する必要がある場合、このメモリ領域にアクセスします。



ほとんどのコンピューターのディスプレイは、1秒間に60回更新されます。 そのため、ブラウザーは1秒あたり60フレームを生成しようとします。 これは、ブラウザがすべての作業（CSSスタイルの分析、レイアウト、レンダリング）に16.67ミリ秒しかないことを意味します-フレームバッファーのすべてのスロットを色に対応する数字で埋めます。 この2つのフレーム間の時間間隔（16.67ミリ秒）は、フレームバジェットと呼ばれます。



人々は時々フレームの欠落について言及するのを聞くことができました。 欠落したフレームは、システムが予算に収まらない場合です。 ディスプレイは、ブラウザがフレームの表示を完了する前に、フレームバッファから新しいフレームを取得しようとします。 この場合、ディスプレイには再び古いバージョンのフレームが表示されます。



紛失したフレームは、フリップブックの破れたページと比較できます。 前のページから次のページへの中間リンクが失われたため、アニメーションがフリーズして動き始めます。







したがって、ディスプレイが再びチェックする前に、すべてのピクセルをフレームバッファーに入れる時間が必要です。 ブラウザがこれを行うためにどのように使用され、技術が時間とともにどのように進化したかを見てみましょう。 そうすれば、このプロセスを高速化する方法を理解できます。

レンダリングとレイアウトの簡単な歴史

ご注意 レンダリングとレイアウトは、ブラウザーのレンダリングエンジンが互いに最も異なる部分です。 単一プラットフォームのブラウザー（EdgeおよびSafari）は、マルチプラットフォームのブラウザー（FirefoxおよびChrome）とは少し異なります。



最初のブラウザでも、ページのレンダリングを高速化するための最適化がいくつかありました。 たとえば、ページをスクロールするとき、ブラウザはページの既にレンダリングされた部分を移動しようとし、次に空きスペースにピクセルを描画しようとしました。



変更内容を計算し、変更された要素またはピクセルのみを更新するプロセスを無効化と呼びます。



時間が経つにつれて、ブラウザーは四角形の無効化など、より高度な無効化手法を使用し始めました。 ここでは、画面の変化する領域の周りの最小の長方形が計算され、これらの長方形内のピクセルのみが更新されます。



ここで、ページ上で少数の要素のみが変更された場合、たとえば点滅カーソルのみがあった場合、計算量は実際に大幅に削減されます。







しかし、ページの大部分が変更されてもあまり役に立ちません。 そのような場合、新しい技術を発明する必要がありました。

レイヤーとレイアウトが表示されます

ページの大部分を変更するときは、少なくともいくつかの場合、レイヤーを使用すると非常に役立ちます。



ブラウザのレイヤーは、漫画の描画に使用されていたPhotoshopのレイヤーまたは薄い滑らかな紙のレイヤーに似ています。 一般に、さまざまなレイヤーにさまざまなページ要素を描画します。 次に、これらのレイヤーを互いの上に配置します。



長い間、ブラウザはレイヤーを使用していましたが、レンダリングの速度が常に向上するとは限りませんでした。 最初は、要素の正しいレンダリングを保証するためだけに使用されていました。 彼らはいわゆる「ポジショニングコンテキスト」（スタッキングコンテキスト）を実装しました。



たとえば、ページに半透明の要素がある場合は、独自の位置コンテキストにある必要があります。 つまり、独自のレイヤーがあり、その色を下にある要素の色と混ぜることができます。 これらのレイヤーは、フレームのレンダリングが終了するとすぐに破棄されました。 次のフレームでは、レイヤーを再描画する必要がありました。







ただし、これらのレイヤーの一部の要素はフレームごとに変化しません。 たとえば、通常のアニメーションを想像してください。 ヒーローが前景に移動しても、背景は変わりません。 背景レイヤーを保存して再利用する方がはるかに効率的です。



これはブラウザがしたことです。 彼らはレイヤーを保存し始め、更新のみを変更しました。 また、場合によっては、レイヤーがまったく変更されませんでした。 たとえば、アニメーションが画面上を移動する場合や要素をスクロールする場合など、わずかに移動するだけです。







レイヤーを共同配置するこのプロセスは、レイアウトと呼ばれます。 リンカは次のオブジェクトを処理します。

• ソースラスターイメージ：背景（コンテンツをスクロールする空白のウィンドウを含む）およびスクロールコンテンツ自体。
• ターゲットビットマップは、画面に表示されるものです。

最初に、リンカは背景をターゲットビットマップにコピーします。



次に、スクロールするコンテンツをどれだけ表示する必要があるかを把握する必要があります。 この部分をターゲットビットマップの上にコピーします。







これにより、メインスレッドでのレンダリングの量が削減されます。 しかし、メインスレッドはまだレイアウトに多くの時間を費やしています。 また、メインスレッドにはリソースを奪い合う多くのプロセスがあります。



前にこの例を挙げました。メインスレッドはフルスタック開発者のようなものです。 彼は、DOM、レイアウト、およびJavaScriptを担当しています。 また、彼はレンダリングとレイアウトも担当しています。







メインスレッドでレンダリングとレイアウトに費やされる1ミリ秒は、JavaScriptまたはレイアウトからかかった時間です。







しかし、ここには他のハードウェアがあり、ほとんど何もしません。 また、グラフィック処理用に特別に作成されています。 90年代のゲームがフレームをすばやくレンダリングするために使用していたGPUについてです。 それ以来、GPUはより大きく、より強力になりました。

ハードウェアアクセラレーションレイアウト

そのため、ブラウザ開発者はGPUの仕事を移し始めました。



理論的には、2つのタスクをグラフィックアクセラレータに転送できます。

1. 描画レイヤー。
2. レイヤーを相互にレイアウトします。

レンダリングをGPUに伝えるのは難しい場合があります。 そのため、通常、マルチプラットフォームブラウザはこのタスクをCPUに任せます。



ただし、GPUは非常に迅速に構築でき、このタスクを簡単に実行できます。







一部のブラウザは、CPUにリンカースレッドを追加することにより、同時実行をさらに強制します。 彼は、GPUで実行されるすべてのレイアウト作業のマネージャーになります。 つまり、メインスレッドが何か（たとえばJavaScriptの実行）でビジーである場合、リンカーストリームはまだアクティブであり、コンテンツのスクロールなど、ユーザーに見える作業を行います。







つまり、すべてのレイアウト作業がメインスレッドから離れます。 しかし、まだ多くのものが残っています。 レイヤーを再描画する必要があるたびに、これによりメインスレッドが作成され、レイヤーがGPUに渡されます。



一部のブラウザーは、追加のストリームに移動してレンダリングしています（Firefoxでも現在作業中です）。 ただし、この最後の計算（レンダリング）をGPUに直接転送する方が高速です。

ハードウェアアクセラレーションレンダリング

そのため、ブラウザーはGPUとレンダリングにも転送し始めました。







この移行はまだ進行中です。 一部のブラウザーはGPUですべてのレンダリングを実行しますが、他のブラウザーでは特定のプラットフォームでのみ可能です（たとえば、Windowsのみまたはモバイルデバイスのみ）。



GPUレンダリングはいくつかの結果をもたらしました。 CPUは、JavaScriptやレイアウトなどのタスクにすべての時間を費やすことができました。 さらに、GPUはCPUよりもはるかに高速にピクセルを描画するため、レンダリングプロセス全体が高速になります。 CPUからGPUに転送する必要があるデータの量も減少しました。



ただし、レンダリングとレイアウトのこの分離を維持するには、両方のプロセスがGPUで実行される場合でも、ある程度のコストが必要です。 この分離により、GPUを高速化する最適化オプションも制限されます。



これがWebRenderの出番です。 レンダリング方法を根本的に変更し、レンダリングとレイアウトの違いを平準化します。 これにより、レンダラーのパフォーマンスを最新のWebの要件に合わせて調整し、将来登場する状況に備えて準備できます。



言い換えると、フレームのレンダリングを高速化するだけではなく、フレームをけいれんさせたり減速したりせずに、より安定したレンダリングを望んでいました。 また、4K解像度の仮想現実ヘルメットWebVRのように、多くのピクセルを描画する必要がある場合でも、スムーズな再生が必要です。

最新のブラウザでアニメーションが非常に遅いのはなぜですか？

上記の最適化は、場合によってはレンダリングの高速化に役立ちました。 ページ上で最小限の要素が変更された場合（たとえば、コースのフラッシュのみ）、ブラウザは可能な限りほとんど動作しません。







ページをレイヤーに分割した後、そのような「理想的な」スクリプトの数が増加しました。 いくつかのレイヤーを描画し、それらを相対的に移動するだけであれば、レンダー+レイアウトアーキテクチャは素晴らしい仕事をします。







しかし、レイヤーには欠陥があります。 彼らは多くのメモリを消費し、時にはレンダリングを遅くすることがあります。 ブラウザーは、理にかなっているレイヤーを組み合わせる必要があります...しかし、理にかなっている部分とそうでない部分を正確に特定することは困難です。



そのため、ページ上でさまざまなオブジェクトが移動している場合は、多数のレイヤーを作成する必要があります。 レイヤーはメモリを大量に消費し、リンカへの転送には時間がかかりすぎます。







それ以外の場合、複数あるはずの1つのレイヤーが取得されます。 この単一のレイヤーは継続的に再描画されてリンカーに渡され、リンカーは何も変更せずにレイヤーを構成します。



つまり、レンダリング作業が削除されます。各ピクセルは、必要なく2回処理されます。 レイアウトステージをバイパスして、ページを直接レンダリングするだけで高速になります。







レイヤーが単に役に立たない多くの場合があります。 たとえば、アニメーション化された背景がある場合、レイヤー全体を再描画する必要があります。 これらのレイヤーは、いくつかのCSSプロパティでのみ役立ちます。



ほとんどのフレームが最適なシナリオに適合していても、つまりフレーム予算のごく一部しか占めていなくても、オブジェクトの動きは断続的なままです。 ジャークとスローダウンを知覚するには、最悪のシナリオに適合するフレームを数個だけ失うだけで十分です。







これらのシナリオは、パフォーマンスクリフと呼ばれます。 これらの最悪のシナリオ（アニメーション化された背景など）の1つに遭遇するまで、アプリケーションは正常に動作するようです-フレームレートは突然限界まで低下します。







しかし、あなたはそのような崖を取り除くことができます。



どうやってやるの？ 3Dゲームエンジンの例に従ってください。

GPUをゲームエンジンとして使用する

どのレイヤーが必要なのか疑問に思うのをやめたらどうでしょうか？ レンダリングとレイアウトの間のこの中間ステップを削除し、各フレームの各ピクセルのレンダリングに戻るとどうなりますか？



それは馬鹿げたアイデアのように思えるかもしれませんが、いくつかの場所ではそのようなシステムが使用されています。 最新のビデオゲームでは、すべてのピクセルが再描画され、ブラウザーよりも毎秒60フレームのレベルの信頼性が高くなります。 彼らは異常な方法でそれを行います...再描画のための領域を最小化する無効化とレイヤーのためにこれらの長方形を作成する代わりに、画面全体が単に更新されます。



この方法でWebページをレンダリングすると、はるかに遅くなりますか？



CPUでレンダリングを行う場合、はい。 しかし、GPUはこの種の作業用に特別に設計されています。



GPUは、最大限の並列処理で構築されています。 Styloに関する前回の記事で並行性について話しました 。 並列処理のおかげで、コンピューターはいくつかのタスクを同時に実行します。 同時に実行されるタスクの数は、プロセッサのコアの数によって制限されます。



通常、CPUには2〜8個のコアがあり、GPUには少なくとも数百個、多くの場合1000個を超えるコアがあります。



ただし、これらのコアの動作は少し異なります。 CPUコアのように、完全に独立して機能することはできません。 代わりに、通常、ある種のコラボレーションタスクを実行し、異なるデータに対して1つの命令を実行します。







これは、ピクセルを埋めるときに必要なものです。 すべてのピクセルを異なるコアに分散できます。 GPUは同時に数百のピクセルで動作するため、CPUよりもはるかに高速にピクセルの充填を実行します...ただし、すべてのコアに作業がロードされている場合のみです。



カーネルは同じタスクで同時に動作する必要があるため、GPUには実行するステップがかなり制限されており、プログラミングインターフェイスは非常に限られています。 仕組みを見てみましょう。



最初のステップは、GPUに何を描画するかを正確に伝えることです。 これは、オブジェクトのフォームとそれらを記入するための指示を与えることを意味します。



これを行うには、パターン全体を単純な形状（通常は三角形）に分割します。 これらの形状は3D空間にあるため、一部の形状は他の形状を隠す場合があります。 次に、すべての三角形の頂点を取得し、x、y、z座標を配列に追加します。







次に、GPUコマンドを送信してこれらのフォームを描画します（描画呼び出し）。







この瞬間から、GPUは動作を開始します。 すべてのコアが一度に1つのタスクを実行します。 彼らは次のことを行います。

1. すべての形状の角度を決定します。 これは、頂点シェーディングと呼ばれます。
   
   
   
   
2. 頂点を結ぶ線を設定します。 これで、形状に含まれるピクセルを決定できます。 これは、ラスタライズと呼ばれます。
   
   
   
   
3. どのピクセルが各形状に属しているかがわかったら、各ピクセルを調べて色を割り当てることができます。 これは、ピクセルシェーディングと呼ばれます。
   
   
   
   

最後のステップの実行方法は異なります。 特定の指示を与えるために、「ピクセルシェーダー」と呼ばれる特別なプログラムがGPUで動作します。 ピクセルシェーディングは、プログラム可能なGPU機能の数少ない要素の1つです。



一部のピクセルシェーダーは非常に単純です。 たとえば、シェイプ全体が1つの色で塗りつぶされている場合、シェーダーは単純にこの色をシェイプの各ピクセルに割り当てる必要があります。



しかし、たとえば背景画像には、より複雑なシェーダーがあります。 ここでは、画像のどの部分がどのピクセルに対応するかを調べる必要があります。 これは、アーティストが画像を拡大または縮小するのと同じ方法で行うことができます...画像の上に各ピクセルの正方形のグリッドを配置します。 次に、各ボックス内の色見本を取り、ピクセルの最終的な色を決定します。 これはテクスチャマッピングと呼ばれます。これは、ここで画像（テクスチャと呼ばれる）がピクセルに重ね合わされるためです。







GPUは、各ピクセルのピクセルシェーダーを参照します。 異なるコアは異なるピクセルで並行して動作しますが、すべて同じピクセルシェーダーが必要です。 GPUにオブジェクトの形状を描画するように指示するとき、同時に使用するピクセルシェーダーを示します。



ほとんどすべてのWebページでは、ページの異なる部分に異なるピクセルシェーダーが必要です。



シェーダーはrenderコマンドで指定されたすべてのピクセルに対して機能するため、通常、これらのコマンドをいくつかのグループに分ける必要があります。 それらはパッケージと呼ばれます。 すべてのカーネルを可能な限りロードするには、それぞれに多数の数字を含む少数のパッケージを作成する必要があります。







これが、GPUが数百または数千のコアに作業を分散する方法です。 これらはすべて、各フレームをレンダリングする際の並外れた並行性のためです。 しかし、このような並外れた並行性があっても、多くの作業が残っています。 適切なパフォーマンスを実現するには、問題の設定に賢明に対処する必要があります。 これがWebRenderの出番です...

WebRenderがGPUで機能する方法

ページをレンダリングするためにブラウザーが実行するステップを覚えておいてください。 ここで2つの変更が発生しました。

1. レンダリングとレイアウトの分離はなくなりました...両方のプロセスが1つのステップで実行されます。 GPUは、グラフィックスAPIから受信したコマンドによって導かれ、同時にそれらを作成します。
2. レイアウトにより、レンダリング用の異なるデータ構造が提供されます。 以前は、フレームツリー（またはChromeの視覚化ツリー）と呼ばれるものでした。 そして今、それは表示リストを渡します。

表示リストは、高レベルの描画命令のコレクションです。 特定のグラフィックスAPIの特定の指示を使用せずにレンダリングする必要があるものを示します。



新しい何かを描画する必要があるとすぐに、メインスレッドは表示リストをRenderBackendに渡します。これはCPUで実行されるWebRenderコードです。



RenderBackendのタスクは、高レベルの描画命令のリストを取得し、それをGPUのコマンドに変換することです。GPUはパッケージにバンドルされて実行を高速化します。







次に、RenderBackendはこれらのパケットをリンカースレッドに渡し、リンカースレッドはさらにGPUに渡します。



RenderBackendは、レンダリングコマンドをGPUで最大速度で実行することを望んでいます。 これを行うには、いくつかの異なる手法が使用されます。

リストから不要なシェイプを削除する（早期カリング）

時間を節約する最善の方法は、まったく働かないことです。



まず、RenderBackendは表示リストを短縮します。 画面に実際に表示されるリスト項目を決定します。 これを行うために、彼はアイテムがスクロールリストにあるウィンドウからどれだけ離れているかを調べます。



Figureがウィンドウ内に収まる場合、表示リストに含まれます。 そして、図のどの部分もここに該当しない場合、リストから除外されます。 このプロセスはアーリーカリングと呼ばれます。

中間構造の数を最小限に抑える（レンダリング用のタスクツリー）

これで、ツリーには必要な形状のみが含まれます。 このツリーは、前に説明した位置関係で整理されています。



CSSフィルターや位置コンテキストのような効果は、物事をもう少し複雑にします。 たとえば、透明度が0.5の要素があり、子要素があります。 あなたはすべての子供たちも透明であると思うかもしれません...しかし、実際にはグループ全体が透明です。







このため、まず各グループを完全に透明にして、グループをテクスチャに持ってくる必要があります。 次に、親オブジェクトに配置すると、テクスチャ全体の透明度を変更できます。



位置コンテキストは相互にネストできます...親オブジェクトは別の位置コンテキストに属することができます。 つまり、別の中間テクスチャに描画する必要があります。



これらのテクスチャにスペースを割り当てるのは高価です。 同じ中間構造上のすべてのオブジェクトを最大限に収容したいと考えています。



GPUがタスクに対処できるように、レンダリング用のタスクツリーを作成します。 他のテクスチャの前に作成する必要があるテクスチャを示します。 他のテクスチャから独立したテクスチャは、最初のパスで作成できます。つまり、1つの中間テクスチャに結合できます。



したがって、半透明の正方形を使用した前述の例では、最初のパスで正方形の1つの角に色を付けます。 （実際、すべてがもう少し複雑ですが、ポイントがあります）。







2番目のパスでは、この角度を正方形全体に複製し、塗りつぶします。 次に、不透明な正方形のグループをレンダリングします。







最後に、テクスチャの透明度を変更し、画面に表示される最終テクスチャの適切な場所に配置するだけです。







レンダリング用のタスクツリーを構築したら、画面に表示する前にレンダリングオブジェクトの最小数を見つけます。 これらのテクスチャにスペースを割り当てるのは高価だと言ったので、これは良いことです。



タスクツリーは、タスクのバンドルにも役立ちます。

レンダリング用のグループ化コマンド（バッチ処理）

既に述べたように、それぞれに多数の図を含む少数のパッケージを作成する必要があります。



パッケージを慎重に作成すると、レンダリングが大幅に高速化されます。できるだけ多くのオブジェクトをパッケージに詰め込む必要があります。この要件はいくつかの理由で提唱されています。



まず、CPUがGPUに描画コマンドを発行するたびに、CPUには常に他の多くのタスクがあります。彼は、GPUのセットアップ、シェーダープログラムのロード、さまざまなハードウェアバグのチェックなどの世話をする必要があります。この作業はすべて蓄積されており、CPUが実行している間、GPUはアイドル状態になります。



第二に、状態を変更するための特定のコストがあります。パッケージ間でシェーダーの状態を変更する必要があるとしましょう。通常のGPUでは、すべてのカーネルが現在のシェーダーからのジョブを完了するまで待つ必要があります。これは、パイプラインのドレインと呼ばれます。パイプラインが空になるまで、残りのコアはスタンバイモードになります。このため、バッグをできるだけしっかりと満たすことをお勧めします。通常のデスクトップPCの場合、各フレームに100個未満のレンダリングコマンドを残すことをお勧めします。また、各コマンドに数千の頂点を挿入することをお勧めします。したがって、最大値は並列性から絞り出されます。タスクツリーの各パスを表示して、どのタスクで1つのパッケージにグループ化するかを確認します。















現在、各タイプのプリミティブには異なるシェーダーが必要です。たとえば、ボーダーシェーダー、テキストシェーダー、イメージシェーダーがあります。







これらのシェーダーの多くは組み合わせることができるため、グループ化されているにもかかわらず、さらに大きなパッケージを作成できると考えています。



タスクはGPUに送信する準備がほぼ整いました。ただし、まだ解決できる作業が少しあります。

不透明度とアルファチャネルパスでのピクセルシェーディングの動作の削減（Z拒否）

ほとんどのWebページには、多くの重複する図形が含まれています。たとえば、テキストフィールドはdivの上部（背景あり）の上にあり、bodyの上部（背景なし）にあります。



ピクセルの色を決定する際、GPUは各図のピクセルの色を計算できます。ただし、最上層のみが表示されます。これはオーバードローと呼ばれ、GPUの時間の無駄です。







したがって、最初に最上位レイヤーをレンダリングできます。次の形状のピクセルのレンダリングに関しては、そのピクセルに既に値があるかどうかを確認します。存在する場合、不要な作業は実行されません。







確かに、小さな問題があります。図が半透明の場合、2つの図の色を混ぜる必要があります。そして、すべてが正しく見えるように、レンダリングはボトムアップで行われるべきです。



したがって、作業を2つのパスに分割します。最初に不透明度を通過します。すべての不透明な図形を上から下にレンダリングします。他の人によって閉じられているすべてのピクセルのレンダリングをスキップします。



次に、半透明の形状に進みます。下から上に描かれます。半透明のピクセルが不透明の上にある場合、それらの色は混合されます。不透明なものの背後にある場合、計算されません。



不透明度とアルファチャネルに応じた2つのパスへの分割は、不要なピクセルの計算をさらにスキップしてZカリングと呼ばれます。



これは単純な最適化のように思えるかもしれませんが、ここでは大きなメリットが得られます。一般的なWebページでは、処理するピクセル数が大幅に削減されます。現在、さらに多くのタスクを不透明度パスに移動する方法を探しています。



現時点では、フレームを準備しています。余分な作業を削除するために最善を尽くしました。

...そして、レンダリングの準備ができました！

GPUはパッケージを構成およびレンダリングする準備ができています。

免責事項：GPUにすべてが残っているわけではありません

CPUはまだレンダリング作業の一部を実行します。たとえば、CPU上の文字（グリフと呼ばれます）をテキストブロックでレンダリングします。 GPUでこれを行うことは可能ですが、コンピューターが他のアプリケーションでレンダリングするグリフとピクセルごとに対応させることは困難です。そのため、GPUでフォントをレンダリングするときに人々が混乱する可能性があります。Pathfinderプロジェクトの一環として、GPU上でグリフレンダリングを移動する実験を行っています。



しかし今、これらのものはCPU上のビットマップに描画されています。次に、GPUのテクスチャキャッシュにロードされます。通常、このキャッシュは変更されないため、このキャッシュはフレームごとに保存されます。



そのようなレンダリングはCPU上に残りますが、それでも高速化の可能性があります。たとえば、フォント文字をレンダリングするとき、さまざまな文字をすべてのコアに分散します。これは、スタイルの計算を並列化するためにStyloが使用するのと同じ手法を使用して行われます... 作業をインターセプトします。

将来のWebRender

2018年に、Quantum Renderの一部としてFirefoxにWebRenderを実装する予定です。FirefoxQuantumの最初のリリース後のいくつかのリリースです。その後、既存のWebページはよりスムーズに動作します。また、Firefoxブラウザーは、画面のピクセル数を増やす場合にレンダリングパフォーマンスが重要であるため、新世代の4K高解像度ディスプレイに対応します。



しかし、WebRenderはFirefoxだけに役立つわけではありません。また、WebVRでの作業では、4K解像度で90 FPSの速度で各目に対して異なるフレームをレンダリングする必要があります。



対応するフラグを手動でアクティブにした場合、WebRenderの最初のバージョンはFirefoxですでに利用可能です。統合作業が進行中であるため、パフォーマンスは最終リリースの場合ほど高くありません。WebRenderの開発を監視する場合は、GitHubリポジトリまたはQuantum Renderプロジェクト全体に関する毎週のニュースを公開しているFirefox Nightly Twitterアカウントを確認してください。



著者について：Lin Clarkは、Mozilla Developer Relationsのエンジニアです。彼女はJavaScript、WebAssembly、Rust、およびServoを使用しており、プログラマーの絵を描くのが大好きです。