MozillaのWebRenderは、カクつく15 FPSのページをゲームエンジン方式のレンダリングで60 FPSに引き上げた

ブラウザは長年、より少ない処理で滑らかさを高めてきた。変更された矩形だけを無効化し、部分をレイヤーとしてキャッシュし、それらを合成し、最終的に両方の処理をGPUへ移した。2017年10月のMozilla Hacksで、Lin Clarkはなぜページが依然としてカクつくのかを説明した。レイヤーはメモリと転送時間を消費し、ブラウザはページに必要なレイヤー数を推測しなければならない。レイヤーが多すぎるとメモリを圧迫してコンポジターが遅れ、少なすぎると再描画されたレイヤーが何も変わっていないのに合成され、すべてのピクセルに二度触れることになる。背景色のアニメーションは、どうであれレイヤー全体の再描画を強制する。

Servoの技術であり、Quantum RenderとしてFirefoxに導入されるWebRenderは、別の前例に従った。3Dゲームエンジンは毎フレームすべてのピクセルを再描画し、ピクセルを並列にシェーディングする数百から数千のコアを持つGPU上で、ブラウザよりも確実に60 FPSを維持する。そこでWebRenderはペイントと合成の境界を取り除いた。レイアウトの出力は、特定のグラフィックスAPIに縛られない高水準の描画命令のディスプレイリストになった。WebRenderのRenderBackendはそのリストをバッチ化されたGPUドローコールに変換し、GPUはレイヤーの推測なしに、毎フレームページの可視シーン全体を再描画した。

フレーム全体の再描画を手頃なコストにするには、処理の排除が必要だった。画面外の項目はGPUに到達する前にカリングされた。レンダータスクツリーは、フィルターやスタッキングコンテキストのための高コストなオフスクリーンテクスチャの最小数を計画した。ドローコールはGPUの並列コアを忙しく保つためにバッチ化された。レンダリングは、覆われたピクセルをスキップする不透明の前から後ろへのパスと、半透明の後ろから前へのパスに分割された。記事によればこれはzカリングであり、典型的なページで大きな効果があった。テキストのグリフはCPUの処理のままだが、フレーム間で保持されるテクスチャにキャッシュされた。

目標は速度だけでなく一貫性だった。性能の崖がなく、ディスプレイがどれほど大きくても、ページのどれほど多くが変わっても、滑らかな60 FPSを保つことだ。記事は、Chromeや当時のFirefoxで15 FPSでしか動かなかったページがWebRenderでは60 FPSで動いたと報告し、この取り組みを4Kディスプレイと、各目ごとに90 FPSでフレームをレンダリングするWebVRへの準備と位置づけた。

レイヤーの推測をやめる。GPUに高水準のディスプレイリストを渡し、ゲームエンジン方式で毎フレームページ全体を再描画する

GPUはピクセルを並列にシェーディングする数百から数千のコアを持っているため、可視ページ全体を毎フレーム再描画することは、CPU規模の仕事ではなく、GPUが作られた本来のワークロードである。

保持されたディスプレイリストはシーンの小さくAPI非依存な記述であるため、CPUは命令を一度構築するだけで、RenderBackendはピクセル処理が始まる前にそれらをカリング、順序付け、バッチ化できる。

シーン全体の再描画はレイヤーの推測とその失敗モードを取り除く。レイヤー数の誤判断も、ピクセルの二重処理もなくなり、フレーム時間が性能の崖から落ちることがなくなる。

処理の排除が再描画を安価に保つ。カリング、より少ないオフスクリーンターゲット、バッチ化、zカリングがGPUのシェーディング量を減らし、CPUでレンダリングされるグリフはフレームごとの経路ではなくテクスチャキャッシュに置かれる。

増分のヒューリスティックが最悪ケースの崖に繰り返しぶつかるなら、モデルを変える。シーン全体を一度記述し、毎フレームそれを大規模並列ハードウェアに再描画させる

WebRenderはその後のFirefox Quantumリリースには含まれていなかった。Lin Clarkは記事のコメントで、Firefox 57より後になるまで搭載されないと書き、記事はQuantum Renderプロジェクトの下で2018年まで統合を計画しており、初期バージョンはすでにフラグの背後で利用可能だった。記事がリンクしたデモは、Chromeや当時のFirefoxで15 FPSで動いたページがWebRenderでは60 FPSで動くことを示し、この解説記事は2017年10月10日にHacker Newsで853ポイントと207コメントを集めた。