2007-06-22
■[Mozilla][cairo] cairoを使うということ
俺は別に中の人でもなんでもないのですが、Geckoがcairoベースになることを肯定的にとらえている一人として、Piroさめのようにどうしてcairoなの?cairoとか変なものにこだわるから、ブラウザとしての進化が遅れてるんじゃないの?(印象訳)という風に感じる理由について考えてみました。
誇大広告と現実のギャップ
Firefox 3のレンダリングエンジンになるGecko 1.9において、cairoというベクトル描画ライブラリを使うようになる、ということが大きな変更点として宣伝されてきました。日本のニュースサイトでも取り上げられていました。
まずこれが間違いだと俺は思っています。というのは、Geckoがcairoベースになるよ、ということ自体では、ほとんどユーザーメリットがないのに、それがユーザー向けの宣伝として伝えられているからです。
実際、cairoベースにするために、ものすごく大量のコードが変更され、それによって大量のバグが埋め込まれ、一時的に性能が劣化しています。それにもかかわらず、cairoベースにすることによって得られる直接のユーザメリットは、「cairoではハードウェアアクセラレーションを利用することができるので、速くなる(かも)」という程度のものです。
今のところ、まだnon-cairoの速度を超えているとは思えませんし、多くのバグを抱えている現状をみると、なんでcairoなの?と、首をかしげてしまうのも仕方ありません。
cairoな世界のその先にあるもの
それでも、Geckoをcairoベースにすることにはメリットがあります。まずは、直接的なメリットから。
- バグの温床となっていた嫌なコードを減らせる。
従来のGeckoでは、自前でgfxと呼ばれるグラフィック抽象化レイヤを作っていて、それがプラットフォーム毎/出力デバイス毎(プリンタとか)に実装をゴリゴリ書いていやなことをしていました。このあたりを、オープンソースプロジェクトであるcairoに任せることで、Geckoではより本質的なレンダリング処理に集中することができます。
(実際には、cairoの開発にMozillaからも凄い人たちが何人も参加しているので、外で仕事をしているだけと見ることもできますが、cairoを専門にやっている人たちも居ますし、他にcairoを利用しているプロジェクトからの貢献も期待できます。) - グラフィック抽象レイヤを一本化して、すっきりした設計にする。
従来のgfxではHTMLやXULのレンダリングに必要な描画機能しか用意されておらず、半透明だとかアンチエイリアス付きだとかベクトル描画だとかいうモダンな描画APIがありませんでした。そのため、そういう新しい描画APIを要求するSVGやcanvasなどは、独自にプラットフォームのより高度なAPI(GDI+やQuartzなど)を呼び出すようになっていました。つまり、gfxを利用する描画コードと、それ以外の描画コードが混ざってけっこうイヤーな感じになっていたのです。
この嫌な状況が、比較的モダンなベクトルベースのグラフィックスライブラリであるcairoですべて置き換えられるわけです。 - 一応、高速化の余地もある。
既に触れましたが、cairoはその実装において3Dハードウェアアクセラレーションを利用するオプションを持っていて、それを利用することで、ソフトウェアだけでは負荷が高い高度な描画の高速化ができるかもしれません。実際に高速に動くまで信じませんが。
さて、ここまででは、ほとんど開発者がコードがすっきりして気持ちいいとか嬉しいとかそういうエゴイスティックな感じがします。しかも、ホントに速くなるの?疑わしいなあ、とゆー雰囲気です。が、上の様なことは次のような副次的なメリットをもたらします。
- (少なくとも長期的には)バグが減る。
メンテナンスするコードが減って、構造がすっきりすることで、バグの修正が容易になります。また、グラフィック抽象レイヤを捨てて作り替えることになるので、そこに起因する根の深いバグを直すチャンスにもなります。 - 高度な描画を利用する機能が作れるように(or作りやすく)なる。
レイアウトコードが利用するグラフィック抽象化レイヤが一本化されたことで、たとえばSVGのなかにHTMLを埋め込んで回転拡大縮小してみたり半透明にしてみたりできたりします。中に<video>要素をつっこんでSVGアニメーションで回転させたり半透明効果をかけたりしたらSilverlight的なこともできたりするのかもしれません。
また、SVGやcanvasの実装もシンプルになるので、新しい機能のサポートが加速される…はずです。
どちらも自信なさげな口調で書きましたが、それは、俺が作っているわけでもないし、まだ具体的なメリットを目にしていないからです。これらのメリットがもっと具体的なものになってはじめてユーザに伝わるのではないかな、と思っています。
しかし残念なことにFirefox 3のタイムスパンでは、具体的なユーザメリットが数えるほどしか出てこないので、ユーザにアピールしない状況になっているのではないかと思うわけです。
結論
cairoの採用は、歴史としがらみと難解なバグを含んだgfxという古いグラフィック抽象化レイヤを窓から投げ捨て、これからの10年を見据えてベクトルベースのグラフィック抽象化レイヤに移行するものです。
Mozillaでは、今まで多くの機能について全てを自分たちで作るという愚行を冒してきました(必要なものもあったでしょうが、Geckoを巨大で複雑なものにしてしまった要因であることは確かです)。しかし今回は、GTK+、Mono(のSystem.Drawing)、Eclipse(SWTのAdvanced Graphics機能)、Inkscapeなどに採用され、それらのプロジェクトからフィードバックや貢献が期待できるcairoというオープンソースプロジェクトにコミットするという正しい選択をしました。
Mozillaはcairoに多大なコードを寄付し、多くのプロジェクトがcairoがちゃんと動いていることを証明し、そしていままでよりも多くの人がMozillaの描画コードの信頼性に貢献してくれます。GeckoはWeb標準やWebを豊かにする新しい機能に集中すればいいのです。つまり、みんなが幸せになるということです。
付録:ついでなのでcairo自体も擁護しておく
最近cairoへの風当たりが強いのでcairoファンの俺としては、とても悲しい状況です。ので、一応こっちも擁護しておいたりします。
cairoは、Geckoでcairo使おうかなーとか言ってた最初の頃は、Linuxでベクトルグラフィックスを使うのにちょこちょこ使われる一つのライブラリに過ぎませんでした。
それが、一年かそこらでWindowsやMacでもそこそこの速度で表示できるようになり、印刷も使えるレベル(Windowsユーザの俺観点で、ですが)になってきたのです。今はまだ機能に不満があるかも知れないですが、いつまでもその状況だとは思いません。
俺はcairo MLをぼちぼち眺めている程度なのですが、それでも見て取れるのは、cairoはベクトルベースの描画ロジックが正しく完璧に高速に動くこと、まずはそこを目指してひた走っている最中だということです。
そのため、たとえばドロップシャドウをサポートするようなラスタライズをリッチにする仕組みは、当初の目標であるベクトル機能の完成をみてその後に検討される機能なのではないかな、と思っています。楽観的に過ぎますか。そうかもしれません。
2006-06-10
■[Cairo][Hack]cairoメモ
最近何をhackしようか悩むことが多くて、いろいろ取りかかっては置いてあります。
そんな中の一つとして、cairoいぢりがあるわけですが、とりあえず必要なところを読み中。
そして調べたものメモ:
- win32: InvertRect (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fillshap_8lh0.asp)
- linux: GXxor (http://xjman.dsl.gr.jp/X11R6/X11/CH07.html)
- mac: Difference Blend Mode? (http://developer.apple.com/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_images/chapter_12_section_7.html#//apple_ref/doc/uid/TP30001066-CH212-CJBIJEFG)
うーむ。Macが曲者の予感だなぁ・・・。
2006-04-10
■[Mozilla][Cairo][Hack]Cairofox
最近はFirefox w/ Cairo(Firfoxのtrunk 3.0aビルド)を毎日試してます。今日試したらテキストを選択するとずれる以下のバグが修正されてます。徐々に実用になりつつある予感。
この辺りのバグはMozilla Japanの中野さんがかなり戦っていらして、その努力に敬服するばかりです。暇があればCairo周りは読んでみたいんですけどねー。
CSS property letter-spacing rendered incorrectly
https://bugzilla.mozilla.org/show_bug.cgi?id=327184
あと気になるところといえば、キャレットおよびフォーカスがXORで描かれていない(XOR描画がニセ!)というあたりでしょうか。それが解決されればもっと広く試して貰える感じになると思います。外野でこんなん書いてるだけじゃなんとも、ですが…。
[追記]プラグインもまだうまく動いてないみたい。現状は運用で回避中。
秀の介
>今日試したらテキストを選択するとずれる以下のバグが修正されてます。
本当に修正されてますか?
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=5017#c2
ここにある2つのテストケースでは、どちらもまだ再現します。
KENZ
上のテストケースはちゃんと動いています。下のテストケースはどう動作するのが正しいのかちょっとよくわからないです。ビルドとしては 2006-04-09-07-trunk の Windows ビルドです。
秀の介
>ビルドとしては 2006-04-09-07-trunk の Windows ビルドです。
Windowsではまともに動いているんですか。
Linuxでは、ダメダメなんですが。
ううむ。
KENZ
確かにLinux版ではダメですねー。以下のビルドで再現しました。
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060411 Firefox/3.0a1
秀の介
>確かにLinux版ではダメですねー。以下のビルドで再現しました。
確認ありがとうございます。
Linuxでもcairoがデフォルトになって、バグの登録が増えて、
少しずつ動き出したようです。
今はひどい状況ですが、少しずつ改善されるかなあと期待しているところです。
同じPiroさんの記事への反応とか、
http://malblue.tumblr.com/post/4044277
ライセンス面についての記事とか合わせて読むと、
http://nobishiro.hp.infoseek.co.jp/diary200504.html#2005.04.24
自前じゃなくて「使えるの」(機能面・ライセンス面)は選択肢がないって云うのが大きそうな。
どちらかというと、使えるのがないときにどう行動するのかって話なのですが、gfxなんかはMozillaの一部としてしか意味がなくて、他のプロジェクトからは使えないので、オープンソースな意味が薄かったと思うのです。たとえば、同じような抽象化レイヤがOOoにもあったりしますが、これがMozilla限定なコードでなければ共用されていたかもしれません。
今回のcairoのアプローチでは、独立した(他のプロジェクトからも使えるような)グラフィック抽象化レイヤ(というかベクトルグラフィックスライブラリ)を採用し、それが使い物になるようにコミットしていくという姿勢が、今回述べたようなメリットをもたらしてくれると考えているのです。
描画レイヤ以外の部分だと、JavaScriptエンジンであるSpiderMonkey(C実装)とかRhino(Java実装)は独立したコンポーネントになっていて他のプロジェクトからも使われたりしています。ここは、AdobeからTamarinというECMAScriptのJITコンパイラを提供してもらったりしている分野ですし、他の企業やプロジェクトとコードをシェアして、同じものをみんなが作らなくて済むのは、素敵なことだなーと。
なんか、書いててぐだぐだだwオープンソースマンセーってことですわ(ぉ