Mozilla Flux

Mozilla関係の情報に特化したブログです。

MozillaはQuantumプロジェクトで過去と訣別し、未来に賭ける

次世代のWebエンジンを構築

Mozillaが最近発表したQuantumプロジェクトは、Firefoxのエンジン部分にあたるGeckoを次世代のWebエンジンへと進化させ、パフォーマンスの飛躍的進歩(quantum leap:直訳は量子跳躍)をもたらす*1。Mozilla Corp.でHead of Platform Engineeringを務めるDavid Bryant氏が"A Quantum Leap for the Web"(和訳)と題する記事でそう発表し、かなりの反響を呼んだ。日本でもIT関係のメディアで多数取り上げられており、目にされた方も多いだろう。

Quantumプロジェクトの進展に伴い、GeckoにはServoの成果が取り込まれていく。ServoはMozillaが2012年ころから開発してきたブラウザエンジンの試作品であり、Rust言語によって構築されている。必然的に、GeckoもRust言語ベースのコンポーネントが増えていく*2。これによりメモリ安全性(Memory Safety)、すなわちプログラムによるメモリ破壊が不可能な状態を段階的に作り上げる。従来は、Geckoにrust(錆)が増えていくことからOxidization(酸化)と呼ばれていた*3が、今後はたとえばQuantization(量子化)と呼ばれるのかもしれない。

Geckoが進化した先にある次世代のWebエンジン(Next Generation Web Engine:以下NGWE)では、マルチコアが当たり前になったCPUに並列的な処理を行わせるとともに、高速化が著しいGPUへの処理のオフロード化も積極的に進める。David Bryant氏は、2017年末までに改善の大きな成果を提供すると明言しているほか、初期の成果は同年前半のうちに出せるだろうとも述べており、Servoの取り込みは急ピッチで進められそうだ。

ServoのパフォーマンスをFirefoxと比較した動画を見れば、その処理の滑らかさは一目瞭然である。通常のWebページでも長大なものになると差は歴然としており、表示時間が数分の1になるとの報告もある。NGWEの開発が進めば、その高速化をFirefoxユーザーも享受することができる。

www.youtube.com

NGWEはWindows、Mac、Linuxに加えてAndroid向けにも提供されるが、iOSに関してはAppleがWebKit以外のブラウザエンジンを認めない限り、Mozillaが提供しようと思ってもできない。また、後述するQuantum CSSの開発計画からすると、Android版NGWEの提供はデスクトップ版よりも遅れそうだ。

サブプロジェクトの成果を順次導入

Quantumプロジェクトは、いくつものサブプロジェクトから構成されている。それらのうち、本記事執筆時点でQuantum - MozillaWikiに掲載されているものを紹介しておこう。ただし、Mozilla's Project Quantum and Servoで言及されているとおり、これらのサブプロジェクトは始まりにすぎない。Servoで試作が完成した機能は、これからも順次NGWEに移植されていくことになるからだ。

Quantum CSS

Quantum CSSはStyloとも呼ばれ、ServoのCSSスタイルシステムをGeckoに統合する(Bug 1243581)。work stealingアルゴリズムを採用してレイアウトの並列処理を行い、増分レイアウトという手法で演算を最小化する。スタイルシステムとは、HTML要素にどのCSSスタイルを適用するかを決めるもの。Servoには高速かつ並列処理が可能なスタイルシステムが実装されており、これを踏まえてStyloでは、Style Resolutionとセレクタマッチングの並列化を行う。増分リスタイルと呼ばれる手法の導入も予定されている(Bug 1288278)。

Quantum CSSの導入は、担当部分の処理に関し、Firefoxユーザーの95%に対し少なくとも2倍の速度向上をもたらす。さらにその約半数のユーザーにおいては、4倍以上の速度になるという。開発の進捗状況を踏まえると、比較的早い段階でFirefoxに投入されそうだ。

Quantum Render

Quantum Renderは、Servoの次世代レンダラであるWebRenderをFirefoxのグラフィックスバックエンドに据える(Bug 1311790)。WebRenderはCSSの処理に特化し、GPU向けに最適化されているため、Chromeが採用しているSkiaよりも効率的だとされる。

Quantum Renderは、OpenGL ES 2.1またはOpenGL 3をサポートした環境で動作し、低レベルな(決め細やかな操作ができる一方で書かなければならないコード量が増える)APIを提供する。また、Retainedモードを採用し、マルチスレッド化されている。これまでGeckoが採用してきたMoz2D APIとの関係は明らかではないが、仮にグラフィックスAPIを全面的に新しくするのであれば、開発には相当な期間を要することだろう。

Quantum Compositor

Quantum CompositorはGeckoのcompositorに独立したプロセスを割り当てるもの(Bug 1264543)で、Servoとは別に「GPUプロセス」の名で開発が進められてきた。compositorは、Webページ内のいろいろな要素が複数のレイヤーにレンダリングされているのを1つにまとめ、スクリーンに送り出す。Firefoxのマルチプロセス化(e10s)に伴い、compositorは既にchromeプロセス内の独立したスレッドとなっているが、このcompositorスレッドがプロセスとして独立するわけだ。

Quantum CompositorはWindows版Nightlyで有効化が目前に迫っており(Bug 1314133)、機能の完成度の点からみれば2017年前半のうちにリリース版で有効化されてもおかしくない。ただ、Windows 7 SP1以降でDXGI 1.2をサポートするアップデートを導入した環境が必須とされている点(Bug 1297822)は気にかかる。Windows 7でも古い環境だとQuantum Compositorが有効にならないと知ったユーザーが、FirefoxのためにOSをアップデートしてくれるかといえば、答えは否だろう。リリース版で有効化されるタイミング(Bug 1307578参照)は、有効化できるユーザーの割合を考慮しつつ決めることになるのではないか。

Quantum DOM

Quantum DOMは、それぞれのタブ(あるいはiframe)を、分離され協調的にスケジューリングされたスレッドに割り当てることで、Webコンテンツの動作をよりスムーズなものとし、プチフリーズの発生を抑える。Mozilla’s Quantum Project | Bill McCloskey's Blogで説明されているように、ユーザースレッド(ユーザー空間で実装されたスレッド機構)を自前のスケジューラで管理し、優先順位を付けて切り替えていく。

多数のタブを開いていても、タブごとにプロセスを割り当てていけばプチフリーズの発生は抑制可能だ。Chromeは現にそうしている。だが、プロセス数の増加は消費メモリの増大につながる。Mozillaの調査研究の結果によれば、現状でcontentプロセスを8以上に増やすことは、メモリ使用量との関係で許容できない。そこで、プロセス内をマルチスレッド化してプチフリーズに対処することにした。マルチプロセスに加えて各プロセス内をマルチスレッド化することは、技術的に決して容易ではないものの、Mozillaはあえてそこにチャレンジする。

Quantum Flow

Quantum Flowは、他のQuantumコンポーネントによってカバーされない領域におけるパフォーマンスの改善を探究するもので、UI最適化が例として挙げられている。

開発プロセスの進化と脱XUL化の加速

Quantumプロジェクトの語られざる意義について、筆者の考えを述べておきたい。手短に言えば、このプロジェクトはWebブラウザの開発のあり方に一石を投じる一方で、従来のGeckoとの互換性をかなり犠牲にすることになるだろう。

まずは前者について。これまで、Firefoxの開発プロセスは、Nightlyから始まり、Auroraで機能をほぼ固め、Betaでテストを繰り返し、リリースに至るという連結列車モデルを採用してきた。大規模な修正を伴う新機能を開発する場合は、Nightlyチャンネルのリポジトリ(mozilla-central)を分岐させたブランチを作成し、適当なタイミングでmozilla-centralに再統合していた。Quantumプロジェクトでは、これらのプロセスの外側に、Servoという実験的なブラウザエンジンを置く形となる。

Webがリッチで複雑なものとなった現在、そのプラットフォームとなるブラウザも複雑化が不可避だ。ブラウザエンジンについても同様であり、革新的な機能を投入することは次第に難しくなっていくだろう。そうした状況のもとでは、過去のしがらみを考慮せずに自由に実験ができる、相対的に小型のブラウザエンジンというカードを持っておくことが強みとなる。なぜなら、巨大化して技術的負債を多く抱えたエンジンをベースに新機能を開発するよりも、実験的なエンジンで得られた成果を移植するほうがコストが少なくて済むからだ。Mozillaの狙いはおそらくこの点にある。

Servoの側から見ると、今後も独立した製品にならないことが決定したと言えそうだ。2014年を振り返ると、Servoをモバイル向け製品に使う話が出ていたし、Firefox OSの基盤に用いることを検討した形跡すらある。だが、Firefox OS自体、スマートフォン向けの開発が打ち切られたうえ、Connected Devices(IoT)にレンダリングエンジンは必須ではないとの判断が下されたことで、進路を絶たれた。Servoの行く末も、Geckoのテストベッドに求めるほかなくなった。

次に、後者について。Mozillaは「跳躍」の先にあるものを懸命に見せようとしているものの、大きく跳べば元の場所から遠く離れるわけで、当然その場所を前提にしていた技術は失われる。具体的には、XULだ。Servoの実験的なフロントエンドがBrowser.htmlと呼ばれていることからも明らかなように、ServoはXULを使用しない。前述したようにNGWEはServoの取り込みを急速に進めるから、脱XUL化もかつてないスピードで進展していくだろう。

これまでも従来型の拡張機能がFirefox本体のバージョンアップに伴って動かなくなることはあったが、本体の修正に追随すれば再び動作するようになる例が大半だった。しかし、脱XUL化は次元の違う問題だ。WebExtensionsベースに移行しない限り、拡張機能は存続できない。完全テーマも同様で、WebExtensionsの一部となる新しいテーマAPIを利用することが要求される。

Quantumプロジェクトが互換性をどれだけ犠牲にするかは、Mozilla自身が一番よくわかっているはず。それでもなお過去と訣別し、未来に賭けるほかないとの決意が、このプロジェクト名には込められている。そこまでしないと生き残れないというところまで、Mozillaは追い詰められているのだ。

(16/11/05追記)
さっそく詳しい人から指摘があったので、本文を修正した。

*1:Firefoxをマルチプロセス化したElectrolysis(電気分解)プロジェクトが分子に関係していたことを踏まえた名称とみられるが、エンジン部分の名称をQuantumに変えるわけではない。

*2:rust-bindgenというバインディングジェネレータを使用する。

*3:Firefox 48に新メディアパーザが最初のRust言語製コンポーネントとして搭載された話は、記憶に新しい。