もずはっく日記(2006年6月)

GFX周りの現在と今後
初回投稿日時: 2006年06月12日03時55分23秒
最終更新日時: 2006年06月12日04時03分52秒
カテゴリ: Mozilla Core
SNS: Tweet (list)

直接聞いた話ではないので一般の人と入手できる情報量は変わらないため、特別新しい話ではないが、ハッカーではなく、テスタ等の協力者のためにthebes等の用語解説も兼ねてGFXまわりの状況について簡単に説明しておく。

まずは従来(Gecko1.8.1以前)の概念は次の図のようになっている。

レイアウトや、描画を指示するコードは概ねXP化されていて、そこからGFXのAPIを使って、GFX経由でOSやツールキット等のネイティブ環境とのやりとりを行っている。しかし、ひとつAPIを変更しようとするだけで全プラットフォームでの変更が必要となるのでとんでもない労力が必要だった。

そこで各プラットフォームとのやりとりをcairoという別のオープンソースプロダクトに任せてしまって、より高性能な描画エンジンの入手と、コード管理の手間を放棄を行おうというのがGecko1.9での構想。

しかし、cairoはCで記述されているため、そのままでは利用しにくい。そこで、thebes(テーベ、古代エジプトの都市、古代ギリシャの都市国家)というC++ラッパーを開発している。

現在のTrunkの設計は次のようになっている。

gfx/src/thebesは従来のgfxのAPIを実装していて、内部ではgfx/thebes以下のthebesを利用しているだけなので、thebesのラッパーと呼べるかもしれない。(この部分も含んでthebesと呼ぶのかどうかは不明。)

実際にcairoのC++ラッパーとしてのコードはgfx/thebes以下にある。cairoそのものがプラットフォームごとにAPIを用意しているのでthebesもそれぞれのプラットフォーム毎に作成されている。(ただ、従来のgfxコードとは違って、そのファイル数は極端に少ない。)このthebesからはcairoを経由せずに、pangoやWin32 APIに直接アクセスしたりもする。そのため、図のように、単純な階層構造にはなっていない。

しかし、レイアウトのコードを中心に見てみると分かるように、パフォーマンスだけではなく、開発効率もこのままでは悪いままなので、次のように変更されていくのではないかと思われる(これは推測)。

つまり、パフォーマンスが要求される局面(テキスト描画等)は、レイアウトコードからダイレクトにthebesにアクセスできるようにして、旧gfxのAPIは整理されるようである。(どのように整理するのかは具体的には決まっていない模様。)つまり、この作業が始まると、non-cairoビルドはできなくなる。