誰がピクセルを作るのか — Layout・Paint・Raster の分担 — ブラウザの仕組み

リクエストがアプリケーションに届くまで

ブラウザURL入力今ここ
DNS名前→IP
ルータ経路選択
ロードバランサ振り分け
Nginx受け口
アプリ処理
DB保存

前のレッスンで公式の12段を並べました。今回はその中から Layout・Paint・Raster・Layerize の4段を取り出し、それぞれが何を出力するのかを見ます。段の名前と、その段が実際に作るものがズレている箇所があります。

まず結論

**Paint はピクセルを塗る段ではありません。** 公式の逐語は `compute a display list` — 描画命令のリストを作る段です。それを `GPU texture tiles` に変えるのは後の **Raster** 段、公式が `create pixels on-screen` と書くのは最後の **Draw** 段です。

そのラスタには **software raster と gpu raster の2モード**があると公式が明記しています。だから「GPUが描く」と一言で断定できません。同じく **`will-change` を書けばレイヤに昇格する**とも仕様は書いていません。仕様の文言は `might` / `perhaps` で、**保証しているのは stacking context と containing block の生成だけ**です。

? 読む前に予測

Chromium公式が Paint 段の説明として書いているのは、次のどれでしょうか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

段の名前と、その段が作るものがズレている

前のレッスンで12段を並べました。今回は、その中の4段が何を出力するのかだけを追います。名前から受ける印象と、実際の出力がズレている箇所があります。

4つの段と、その出力(公式の逐語より)表

段         公式の説明                          出力されるもの
Layout     大きさと位置を決める                the immutable fragment tree
Paint      compute a display list              display list(描画命令のリスト)
Layerize   display list を合成レイヤに分割      composited layer list
Raster     GPUテクスチャタイルに変換する        GPU texture tiles

Paint の行を見てください。 逐語はこうです。

Paint: compute a display list that describes how to raster GPU texture tiles from the DOM.

「塗る」という名前ですが、作っているのは display list です。Chromium ソース内の paint の README はもっと直接的に書いています。

Walks the LayoutObject tree and creates a display item list.

そして、その display list が誰に渡るのか。

The primary responsibility of this directory is to convert the outputs from layout (the LayoutObject tree) to the inputs of the compositor (the cc::Layer list, which contains display items, and the associated cc::PropertyNodes).

Paint 段は、Layout の出力をコンポジタの入力に変換する段です。ピクセルは1つも作りません。

Layout の出力も、名前から想像するものとは違います。公式が挙げるのは the immutable fragment tree です。LayoutNG の解説にはこう書かれています。

While the layout object tree structure closely resembles that of the DOM tree, the fragment tree is an output of layout, not an input to it.

✓ ここまでの確認

Chromium の cc には何種類のラスタのモードがあり、それは何ですか。

具体実物

ではピクセルは誰が作るのか

display list を GPU texture tiles にするのは Raster 段です(create pixels on-screen は最後の Draw 段の説明)。ここで初めてGPUの話が出てきます——ただし、必ずGPUとは限りません。

docs/how_cc_works.md の逐語です。

TileManager is responsible for rasterizing the world of tiles. Each PictureLayer provides a set of Tiles to rasterize, where each Tile is a subrectangle of painted content at a particular scale.

そして重要な一文。

There are currently two modes of raster in cc:

software raster: generate software bitmaps in the raster worker

gpu raster: generate gpu textures by sending paint commands over the command buffer

2つのモードがあります。 software raster はラスタワーカーでソフトウェアビットマップを作り、gpu raster はコマンドバッファ経由で描画命令を送ってGPUテクスチャを作ります。

だから「レンダリングの最後はGPUが描く」という説明は、片方のモードだけを述べていることになります。

cc 自身の役割はこうまとめられています。

cc is responsible for taking painted inputs from its embedder, figuring out where and if they appear on screen, rasterizing and decoding and animating images from the painted input into gpu textures, and finally forwarding those textures on to the display compositor in the form of a compositor frame.

公式文書が自分の用語を自嘲している箇所

docs/how_cc_works.md には、読むと少し驚く注記があります。

cc unfortunately still uses the language of "draw" and “swap” in a number of places, despite the fact that it no longer does either of these things.

もうどちらもやっていないのに、"draw" と "swap" という語がコードのあちこちに残っている、と公式ドキュメントが認めています。名前についても同様です。

It's neither "the" chrome compositor (of course we have many), nor a compositor at all any more. danakj suggests "content collator" as an alternative name.

cc は Chrome Compositor の略とされてきましたが、もはやコンポジタですらないと書かれています。

名前は実装より遅れて変わります。 「Paint だから塗っているはず」「Compositor だから合成しているはず」という推論は、公式のコードベースの中ですら成り立ちません。名前ではなく、その段の入力と出力が何かを確かめる必要があります。

✓ ここまでの確認

CSS Will Change 仕様が `will-change` について「保証している」効果は何ですか。

⇄ 2つを見比べる

具体例 A

Layerize のトレードオフ

レイヤを分けるほど再ラスタは減りますが、GPUメモリを食います。公式は両極端を先に示し、その間で釣り合いを取る段だと説明します。だから「分ければ速い」という単純な規則にはなっていません。

公式が挙げる両極端(逐語の要約)表

全部を1枚に統合   スクロールのたびに高価な再ラスタが要る
chunkごとに分割   再ラスタは避けられるがGPUメモリをすぐ使い果たす
公式の方針       既定は統合。コンポジタスレッドで変化が
               予想されるものだけ統合しない

具体例 B

will-change の仕様文言

事前に最適化を仕込ませるためのヒントですが、仕様は昇格を保証しません。宣言が多すぎるとGPUメモリを使い果たすため、ブラウザは昇格を避けてよい、と仕様自身が書いています。Layerize と同じ資源の制約が、仕様の側にも現れています。

仕様が使っている動詞表

might avoid doing that               昇格を「避けうる」
perhaps rendering them to their own  「おそらく」
A browser might take ... as a signal 「signalとして扱うかもしれない」
保証されるもの                        stacking context と
                                   containing block の生成のみ

片方はChromiumの実装方針、もう片方はW3Cの仕様文言です。書き手も目的も違いますが、同じ慎重さが現れています。共通する構造は何でしょうか。

どちらも「最適化を増やすと何が減るのか」を考えてください。そのうえで、なぜ条件を確定させずに書いているのかを見てください。

★ここは断定も否定もできない — 「transform はレイアウトを起こさない」

この話題で必ず出てくるのが「transform はレイアウトを起こさないから速い」という説明です。本教材の検証では、この通説をそのままの形で裏付ける文言を、Chromium の設計文書と仕様には確認できませんでした。

skip layout / without layout / does not trigger layout などのパターンで一次ソースを検索しましたが、transform がレイアウトを起こさないと明示した文は見つかっていません。

一方、web.dev の解説記事「Stick to Compositor-Only Properties and Manage Layer Count」(最終更新 2015-03-20)は、コンポジタだけで扱えるプロパティについて Today there are only two properties for which that is true - transforms and opacity と明示しています。設計文書や仕様の規定ではありません。

見つかったのは、もっと弱く、もっと限定的な文言です。

Stages of the rendering pipeline can be skipped if they aren't needed. For example, animations of visual effects, and scroll, can skip layout, pre-paint and paint.

この文が言っているのは「視覚効果のアニメーションとスクロールは layout・pre-paint・paint を飛ばせる」ことです。transform というプロパティ名は、この文には出てきません。 しかも can be skipped if they aren't needed という条件付きです。

もう1つ、compositor-thread transform animations という語は key data structures のほうに出てきます。つまり「transform のアニメーションがコンポジタスレッドで動きうる」ことは読み取れます。

ここで重要なのは、だからといって通説が誤りだとも言えないことです。 確認できなかったのは裏付けであって、反証ではありません。「一次ソースで確認できていない」が正確な状態です。この区別を曖昧にすると、今度は逆向きの断定を作ってしまいます。

同様に、「レイアウトはペイントより何倍重い」といった定量的なコスト比も一次ソースには見つかりませんでした。数値で語れる段階にありません。

実務の場面60fps は仕様の要求ではない

もう1つ、この領域で広く語られる数字があります。「1フレーム16.7ms以内に収めなければならない、それが仕様の要求だ」というものです。

HTML仕様の該当箇所には、こう書かれています。

This specification does not mandate any particular model for selecting rendering opportunities. But for example, if the browser is attempting to achieve a 60Hz refresh rate, then rendering opportunities occur at a maximum of every 60th of a second (about 16.7ms).

冒頭で「特定のモデルを義務付けない」と明言し、60Hz は But for example, として挙げられています。 続く部分では、維持できないと判断すれば毎秒30回に落とすかもしれず、ページが見えていなければ毎秒4回かそれ以下にするかもしれない、とも書かれています。

16.7ms を性能目標として使うことは、実務上まったく問題ありません。誤りになるのは「仕様が60fpsを要求している」と出典を付けた瞬間です。前のレッスンで見た「5段モデルは公式仕様だ」とまったく同じ形で、値そのものではなく帰属が誤ります。

この章のまとめ

Paint はピクセルを作らない。 逐語は compute a display list。README は creates a display item list と書く。
Layout の出力は the immutable fragment tree。 an output of layout, not an input to it と明記されている。
display list を GPU texture tiles にするのは Raster 段(create pixels on-screen は Draw 段)。ただし cc には software raster と gpu raster の2モードがあり、「GPUが描く」と断定できない。
Layerize はトレードオフ。 既定は統合し、コンポジタスレッドで変化が予想される property tree state を持つものだけ統合しない。全部分けると GPUメモリを使い果たす。
will-change が保証するのは stacking context と containing block の生成のみ。 昇格は might であり、仕様自身が「宣言しすぎると昇格を避けることがある」と書いている。
★ 「transform はレイアウトを起こさない」は、Chromium 設計文書・仕様では裏付けも反証も取れていない。 明示しているのは web.dev の解説記事(最終更新 2015-03-20)。断定も否定もしないのが正確。
60fps / 16.7ms は仕様の要求ではなく例示値。 仕様は does not mandate any particular model と明記している。
公式ドキュメント自身が "draw" と “swap” というもう実態に合わない名前が残っていると認めている。名前ではなく入出力で段を理解する。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

手元のプロジェクトのCSSから `will-change` を書いている箇所を全部抜き出し、それぞれについて「何が変化すると予想して書いたか」を言えるか確かめる。言えないものは、仕様が想定する使い方(変化を事前に知らせる)から外れている可能性がある
AIに「transform はレイアウトを起こさないので速い、という説明の根拠になる一次ソースを示して」と尋ね、返ってきた出典を実際に開いて該当文言があるか確かめる。本教材の検証では、この通説をそのままの形で裏付ける文言は Chromium 設計文書・仕様には確認できていない(web.dev の解説記事には transforms と opacity を挙げる記述がある)

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

「Layout の出力は render tree である」という説明を、Chromium公式の用語に照らすとどうなりますか。

用語集(5語)

display list: Paint 段の出力。描画命令のリストであってピクセルではない。paint の README は Paint 段について `Walks the LayoutObject tree and creates a display item list.` と書いている。
the immutable fragment tree: 公式が Layout の出力として挙げるもの。`the fragment tree is an output of layout, not an input to it`(LayoutNG の解説より)。
software raster / gpu raster: cc にある2つのラスタのモード。前者はラスタワーカーでソフトウェアビットマップを生成し、後者はコマンドバッファ経由で描画命令を送ってGPUテクスチャを生成する。
layer(cc における定義): 逐語は `A layer is a 2d rectangle of content with integer bounds. It has some transform, clip, and effects on it that describe how it should look on screen.`
will-change の規定上の効果: stacking context と containing block の生成のみ。それ以外は UA への rendering hint であり、レイヤ昇格は保証されない(CSS Will Change Module Level 1、W3C CRD 2022-05-05)。

誰がピクセルを作るのか — Layout・Paint・Raster の分担