Taken SPC

「なぜ cairo なのですか ?」

それは良い質問で gmane.comp.graphics.agg で尋ねられました。 Anti-Grain は非公式のテストにおいて、より速いように見えるので(多くの 2D 指向 API を比較するためのベンチマークフレームワークが本当に必要です)、なぜ Mozilla は cairo を描画ソリューションとして選んだのか疑問に思う人もいるかもしれません。 残念ながら、これまでのところ答えはそれほど満足のいくものではなく多くのカテゴリにわかれています。

• 「C++ は悪いです。」 Anti-Grain はテンプレートを使って C++ で実装されていますが、これは現時点では使い古した議論のように見えます。
• 「cairo にはハードウェア支援があります。」 Anti-Grain は純粋なソフトウェアエンジンですが、cairo には、OpenGL バックエンド(glitz と呼ばれています)があります。 残念ながら、このバックエンドのオーナ (David Reveman) は現在 Xgl の開発で忙しく、メンテナとして兼任できる余裕があるかという問題に悩んでいます。
• 「cairo は PDF/PS を出力します。」 これは cairo の利点の最も強い論拠であるように見えます。

Mozilla はグラフィックス能力を獲得するためと、プラットホーム特有のグラフィックスコードを書くこと責任を捨てさり、cairo 開発者の手に委ねるためにすべての描画を cairo に移行することを決めたように思えます。残念ながら、 2 番目の分野では私たちは本当にあまり得しておらず、Vlad と Stuart が Mac OS X と Windows バックエンドのオーナにならなければならなかったように見えます。 コア な cairo 開発者は Linux で作業しているので Linux はすべての人の注意を引くプラットフォームです。

cairo を採用したことで高度なグラフィックス能力がありますが、それらを使用することは cairo を高速経路【fast paths】から捨てる傾向があります。 通常のウェブページの表示(変形は移動のみ、ピクセル指向のオブジェクト)は高速経路【fastpath】のままでしょうが、一度ページをズームするか SVG コンテンツがあると、私たちはパフォーマンスの問題に直面しはじめるでしょう。

Anti-Grain の主な欠点はそれが将来にわたってハードウェア支援なしの(私が聞けた限り -- 訂正は歓迎します)ソフトウェアソリューションであるということです。グラフィックスハードウェアが、モバイル機器においても、性能がはるかに向上されて きているので、これは今後に対する大きな制限のように見えます。

完全を期すために、私は Xara と彼らのソフトウェアのみの描画カーネルについて言及するべきでしょう。(彼らは cairo よりはるかに速いと主張しています)。 また Inkscape にも内部の 2D 描画エンジンがあります。

ハードウェア支援のされた 2D 指向 API をみると 前述の glitz バックエンドを使った cairo、OpenVG と Amanith を私は知っています。 cairo の glitz は、現在、メンテナが兼任できる余裕があるかという問題がありソフトウェア/ハードウェアのブリッジエンジンのバックエンドであることで妥協するかもしれ ません。OpenVG は OpenGLのような API を持ち(少なくとも OpenGL ES 上に実装されたいくつかの例が登場しています)、主にモバイル市場で採用されています。 Amanith は OpenGL 上の 2D API として実装されていますが、OpenVG API を使用するより、自身の C++ API を設計することを選びました。

Linux におけるグラフィックスの未来としてしばしば売り込まれているライブラリに関して、 cairo ライブラリと cairo の使用する X サーバ能力の両方でさらに多くの開発リソースを必要とするように思えます。 というよりも、より OpenGL にダイレクトなライブラリが提供されるべきです。