Servo Architecture vol.1: ConstellationとPipeline

第三回Servo Readingの成果として、最初はServoのCompositorの話を書くつもりだったんだけど、いきなりCompositorの話を出してもややこしいので、まずはConstellationとPipelineの話をしようと思う。

ブラウザエンジンと一口に言っても、よく知られている通り、その仕事は多岐に渡る。リソースの読み込み、画像のデコード、HTML/CSSのパース、描画ツリーの構築、DOMの構築、JSの実行、結果の出力etc。こうして並べてみるとわかるようにその仕事は多岐に渡る。ましてや最近はOSの抽象層みたいな事もやり始めたので、どんどんと管制対象は増えていくばかり。そうした処理を管制する役割の箇所をServoではConstellationと呼ぶ。最初はengineと呼ばれていたまさにエンジンの中央部分だ。どういったわけかリネームされて今の名前になったわけだけど、ECMAScriptで有名な某日本人とは関係ないらしい。servoのircで「まさかConstellationって名前のヤツがpull request送って来るとは思わなかったよ」みたいなこと言われてたくらいだし（最初に名前が変わった時も面白かったけど、ircがその話になった時は本当に爆笑した）。

現在の実装では、Constellationは渡したurlごとにインスタンスが生成されるようになっているので、処理単位としては、ブラウザの1タブごとに生成されているようなものだと考えるといいだろう。Firefoxの中身になじみの有る人にとっては、xul:browserあたりと対応させて想像しているかもしれない（この場合はもう少し低レイヤーなんだけどね）。この管制役は、そこに束ねた各主要タスクとのメッセージチャンネルを用いて、イベントメッセージの発生に応じて処理を振り分け、ブラウザを回転させることになる。

さて、ブラウザエンジンはただページをレンダリングしてDOMを構築するだけではブラウザたり得ない。そこにはWebをbrowseするための機能としてナビゲーション機能が必要だ。そして、ナビゲーションを行うにはページに相当する単位も必要になってくる。そこでServoではPipelineというモデルを用意している。このPipelineはそれぞれがScriptTask、RenderTask、LayoutTask、それとナビゲーションの状態などを持つ。1ページ=1 Pipelineとは言っても、iframeが絡んだ場合は構成がちょっと異なる。実質別のページだしね。親ページとoriginが違うiframeでは完全に別のPipelineが生成される。same origin iframeでもPipeline間でもScriptTaskのみが共有される。セキュリティ的な価値もあるけれども、設計としての明快さも感じられる。

そして、戻る・進むといったナビゲーションが発生すると、ConstellationはこのPipelineのリストの位置を差し替えることでページのナビゲーションを実現している。

ConstellationとPipelineについての説明はだいたいこんな感じ。次回は、うーん、いつ頃にしましょうか。