Google Developers Japan: Windows 版 Chrome のパフォーマンス改善とネイティブウィンドウオクルージョンの導入

Windows 版 Chrome のパフォーマンス改善とネイティブウィンドウオクルージョンの導入

2022年1月17日月曜日

この記事は Chrome デベロッパー、David Bienvenu による Chromium Blog の記事 "Chrome on Windows performance improvements and the journey of Native Window Occlusion" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 code { background-color: transparent }

ブラウザをタブグループで整理している方でも、ウィンドウに名前を付けている方でも、タブ検索やその他の方法を使っている方でも、目的のタブにたどり着くためにたくさんの機能を使うことができます。速さと好奇心の今回の投稿では、どのウィンドウが表示されているかを利用してどのように Chrome を最適化したかについて説明します。その結果、起動が 25.8% 速くなり、クラッシュは 4.5% 減少しました。背景[1]レンダリングネイティブウィンドウオクルージョンの計算z-order

オクルージョンの計算

理論的には、どのウィンドウがオクルージョン対象かを判断するのは簡単です。しかし実際には、マルチモニタ環境、仮想デスクトップ、透過ウィンドウ、クロークされたウィンドウなど、複雑な要素がたくさん存在します。この点には、慎重に対処しなければなりません。実際にユーザーに表示されているウィンドウをオクルージョン対象と判断してしまうと、ウェブコンテンツが表示されるはずの場所が白くなってしまうからです。また、オクルージョンの計算をしている間に UI スレッドをブロックすることは、Chrome の応答性とユーザーエクスペリエンスが悪化する可能性があるため、避けなければなりません。そこで、次のようにして別のスレッドでオクルージョンの計算をしています。

最小化されたウィンドウは表示されないので、無視する。
別の仮想デスクトップ上にある Chrome ウィンドウはオクルージョン対象とマークする。
ディスプレイのモニターを組み合わせた仮想画面の矩形を計算する。これがオクルージョンされていない画面の矩形になります。
デスクトップで開いているウィンドウについて、前から後の順番に反復処理を行う。見えないウィンドウ、透明なウィンドウ、フローティングウィンドウ（スタイルが WS_EX_TOOLBAR であるウィンドウ）、クロークされたウィンドウ、他の仮想デスクトップのウィンドウ、非矩形ウィンドウ [2] などは無視する。重要な点として、このようなウィンドウを無視すると、オクルージョン対象のウィンドウの一部が表示されているものと見なされる（偽陰性）可能性がありますが、表示されているウィンドウがオクルージョン対象と見なされる（偽陽性）ことはありません。各ウィンドウについて以下を行います。

オクルージョンされていない画面の矩形から対象のウィンドウの領域を引く。
対象のウィンドウが Chrome ウィンドウである場合は、その領域がオクルージョンされていない領域と重なっているかどうかを確認する。重なっていない場合、その Chrome ウィンドウは前にあるウィンドウによって完全に覆われているため、オクルージョン対象になります。

すべての Chrome ウィンドウの計算が終わるまで繰り返す。
この時点で、オクルージョン対象とマークされていない Chrome ウィンドウは表示されていることになり、オクルージョンの計算は終了する。ここで、UI スレッドにタスクをポストし、Chrome ウィンドウの表示状態を更新します。
この操作は、すべて同期ロックを使わずに行われるので、オクルージョンの計算は UI スレッドに最低限の影響しか与えない。たとえば、UI スレッドをブロックしてユーザーエクスペリエンスを悪化させることはありません。

実装についてさらに詳しく知りたい方は、ドキュメントをご覧ください。

オクルージョンの計算タイミングの決定

オクルージョンの計算をし続けると、Chrome のパフォーマンスが低下することになるので、それは避けたいことです。つまり、ウィンドウが表示対象またはオクルージョン対象になるタイミングを検知する必要があります。ありがたいことに Windows では、ウィンドウの移動、リサイズ、最大化、最小化などのさまざまなシステムイベントをトラッキングできます。オクルージョン計算スレッドは、これらのイベントを追跡したいことを Windows に伝えます。そしてイベントが通知されると、イベントを精査して新たにオクルージョン計算を行うかどうかを決定します。非常に短い時間内に複数のイベントを受け取る可能性があるため、オクルージョンの計算は 16 ミリ秒に 1 回を超える頻度では行いません。この時間は、フレームレートが 1 秒あたり 60 フレーム（fps）である場合に 1 フレームが表示される時間に対応します。

リッスンするイベントは、ウィンドウのアクティブ化や非アクティブ化、ウィンドウの移動やリサイズ、ユーザーの画面ロックやロック解除、モニターの電源オフなどです。オクルージョンの計算は必要以上に行いたくありませんが、ウィンドウが表示されるイベントを見逃すわけにはいきません。見逃してしまうと、ウェブコンテンツが表示されるはずの場所が白くなってしまうからです。これは絶妙なバランスです [3]。

リッスンするイベントは、Chrome ウィンドウがオクルージョンされるかどうかに関わるものです。たとえば、マウスを動かすとたくさんのイベントが発生し、カーソルも点滅するたびにイベントを発行しています。そういったイベントはウィンドウオブジェクトとは関係ないので、無視します。また、ツールチップの表示によってオクルージョンの計算がトリガーされることはないので、大半のポップアップウィンドウのイベントも無視します。

オクルージョンスレッドは、さまざまな Windows イベントを検知したいことを Windows に伝えます。UI スレッドは、主要な状態変化（モニターの電源オフ、ユーザーによる画面ロック）が発生した場合にそれを検知したいことを Windows に伝えます。

結果

この機能は、効果を測定する実験と合わせて開発され、2020 年 10 月に M86 リリースの一部としてすべての Chrome Windows ユーザーにロールアウトされました。指標から、この機能をオンにした場合にパフォーマンスが大幅に改善されることがわかります。

起動時間が 8.5% から 25.8% 短縮
GPU メモリ使用量を 3.1% 削減
レンダラー全体の描画フレーム数を 20.4% 削減
レンダラーのクラッシュが発生したクライアントが 4.5% 減少
First Input Delay（初回入力までの遅延時間）が 3.0% 向上
First Contentful Paint（視覚コンテンツの初期表示時間）と Largest Contentful Paint（最大視覚コンテンツの表示時間）が 6.7% 向上

起動時間と初回入力までの遅延時間が改善したのは、Chrome が起動時に 2 つ以上の全画面ウィンドウを復元する場合、いずれかのウィンドウがオクルージョンされる可能性が高いためです。Chrome はそのウィンドウに関する大半の作業を省略できるので、より重要なフォアグラウンドウィンドウのためにリソースを節約できます。

すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ。 [1] 音声や動画を再生しているタブなど、一部のタブは優先度が下がりません。[2] 非矩形ウィンドウの計算は複雑です。これはあまり使われないと考えられていましたが、Windows 7 のデフォルトテーマの特性上、Windows 7 では一般的に使われています。 [3] 最初にこれをリリースしたとき、Citrix で別のユーザーが画面をロックすると、Windows が現在のセッションではないセッションの変化通知を送信してくるため、白いウィンドウが表示されることがすぐにわかりました。詳細はこちらをご覧ください。Eiji Kitamura - Developer Relations Team