Taken SPC

Gran Paradiso Alpha 4 と SVG

Gecko 1.9a4 がリリースされました。このリリースの大きな変更点には cairo 1.3.12 から 1.4.2 への更新と、 SVG テキストコードが cairo を直接利用したものから Mozilla の Thebes グラフィックスレイヤを使ったものへの変更が含まれます。前者はパフォーマンスの大きな向上をもたらし、後者はフォントのより良い選択と特定のフォントに含まれないグリフに対して適切なフォント置換を行います。

1.9a3 から修正されたおもな SVG のバグ:

• グラデーションとフィルタの stop-color で透明度をサポート。
• リンクの target 属性を反映
• テキストコンテナのメモリリークを修正
• userSpaceOnUse のパターンを参照したストロークの水平線が描かれない
• SVG テキストを Thebes の API を使ったものに切替。
• patternContentUnits="objectBoundingBox" が正しく移動されない。
• パターンを参照している要素の透明度が反映されない。
• 参照されたパスが変更されても <textPath> が更新されない。
• コードの再構築
• セキュリティ修正

あなたのコンテンツをテストして、バグを発見した場合にはテストケースを添えてバグを提出してください。

SMIL アニメーションと SVG フォント

以前私は SVG フォントとアニメーションが Firefox 3 にむけた私たちの開発スケジュールにないという事実について議論を書きました。ここに、これらの機能を実装するのに必要だろうものに関するいくつかの考えがあります。

2 つの中で SVG フォント はより簡単です。 bug 375141に SVG テキストを 「おもちゃ」 API 経由で cairo を直接使うものから、 mozilla のその他の部分でフォントを処理しているのとおなじコード (代替フォント機能を与えてくれます) に切替える、現在レビュー中のパッチがあります。 cairo グラフィックスプロジェクトは ユーザフォント API の作業をしてきており、cairo 1.6 の ロードマップ にそれを載せています。 始めるために、人は (どんな文脈でも SVG フォントを使うことができる CSS の @font-face よりも) 描画される SVG ファイルに埋め込まれている SVG フォントの場合に集中したがっているかもしれないと思います。 さらに言えば、グリフが "d" 属性のパスデータである <glyph> の基本形から始めるのが最も簡単でしょう。 パスデータの分析は、Mozilla では既に実装されており、 nsSVGPathDataParserToInternal クラスを通して再利用できます。SVG フォントを解決するうえで最も困難な問題は、おそらく、 SVG (塗りと様々な SVG DOM API) に必要な場合だけ cairo がユーザフォントを知っていることを確実にして、他のドキュメントに「漏らさ」ないことでしょう。

SMIL アニメーション はより大きなプロジェクトですが、Brian Birtles が学校のプロジェクトとして引き受けたため、最初からやらなくても良いでしょう。プロジェクトに関する彼の記事は現在のパッチに対しては少し時代遅れですが、選択されたアーキテクチャについて役に立つ情報を提供します。最新のパッチは bug 216462 に添付されているので見つけることができるでしょう。そのバグのコメント13 で次に必要なステップに関する Brian の考えを見つけることができます。これは deCOMtamination のような様々なパッチのクルーンアップに主に関係します。これの後にスタイルシステムによって管理されているプロパティ (例: 色やストロークの幅)をアニメーションさせる方法を理解することと、他の SMIL 要素 (<set>, <animateMotion>, <animateColor>, 及び <mpath>) を実装することなどがきます。

最後の注意として、もし Firefox 3 に向けてこれらの機能に取り組みたいなら、機能凍結は現在 2007 年 7 月に予定されています。質問があるか、Mozilla SVG コードを理解するポインタが欲しいなら、mozilla.dev.tech.svg ニューズグループに投稿するか、 irc.mozilla.svg #svg IRC チャンネルで私たちをみつけることができるか調べてください。

Gecko 1.9a3 がリリースされました。これは Alpha 2 で発生していたSVG の大きなリグレッションを修正しており、テストの良い候補です。問題を見つけた場合、テストケースと一緒にバグを登録してください。

このアルファ版では cairo が更新されなかったため、Mac OS X のテキストは依然多くの問題を抱えています。Mac OS X のもうひとつの問題は cairo の Quartz バックエンンドが繰り返しなしのサーフェースのペイントをサポートしていないため、フィルタがタイル状のゴミが入ることです。

1.9 Alpha 2 から修正された主な SVG バグ:

• octaves 属性が 10 以上のfeTurbulence 要素がハングする
• 直前に foreignObject 要素によって占領されていた領域が再描画されない。
• W3C SVG WG の意見に賛成して、フィルタの部分領域領域を変更。
• feColorMatrix 要素の実装。
• <a> 要素の中のテキストが描画されない。
• テキストの更新を単純化
• 座標のコンテクストコードを書き直し
• サーフェースに直接関係ある要素 (フィルタ、マスク) が ビッグエンディアンマシン (例えば PowerPC) で動かない。
• 外がわの SVG へ viewBox 属性を追加しても働かない。
• いくつかの SVG 要素にプレゼンテーション属性がない。
• マーカ用の手書きのオブザーバスキームを nsIMutationObserver に置き換え。
• セキュリティの修正。

Firefox 3 における SVG の優先度

SVG開発に利用可能な最低限のリソースで、 Firefox 3 には 私たちは Firefox 3 タイムフレームの中で開発努力の優先付けに関していくつかの苦渋の決断をする必要があります。私たちはセキュリティ問題が非常に重要であり、その他の変更に如何なるリソースも費すよりも前に解決されるべきと信じています。セキュリティの次に、仕様準拠のために現在の実装を洗練させるか SMIL 宣言的アニメーションや SVG フォントのような新機能の実装するかを選ばなくてはなりません。

私たちは、高品質の SVG 実装を出荷することが重要であると感じており、限られたリソースをセキュリティと仕様への正確さの修正にあてるつもりです。つまり現在の開発リソースでは SMIL と SVG フォントは Firefox 3 に入りません。それらを入れる最も近い機会はおそらく 2008 年後半になるでしょう。

Firefox 3 に更なる SVG の機能が必要だと考えている全ての方、個人あるいは法人、に「開発努力にリソースを追加することを考えてください」とお願いします。SVG を前進させ続けるため Mozilla の SVG 実装にあなたの時間を割き、貢献してください!

Gran Paradiso Alpha 2 と SVG

Gecko 1.9a2 がリリースされました。a1 から SVG の改良点がとても多くありますが、残念ながら a2 のためにツリーが凍結される直前に見付かったリグレッション (Bug 369402) によって特定の構造を持った SVG ファイルは描画されないでしょう。もしあなたのコンテンツがそのバグでは問題くて他の問題を見付けた場合、テストケースと一緒にバグを提出してください。

もっとも大きな変更の一つは私たちが使っている cairo のバージョンが 1.3.12 にあがったことです。これは多くのパフォーマンスの改善、特に複雑なジオメトリを助けるはずの新しいテセッレータを含んでいます。グラデーションも速くなりましたが、線形グラデーションの reflect モードで視覚的な副作用のバグがあります。

1.9a1 からの主な変更点は以下の通りです:

• テキストは x/y 属性が変更されると移動するでしょう。
• <feMorphology> の初期モードは erode です。
• <image> は、同じ画像が複数回呼び出される場合劇的に、より少ないメモリを使い非常に速くレンダリングされます。
• <feBlend> と <feComposite>, <feFlood>, <feTurbulence> が実装されました。
• テキストノードの削除によって表示が変更されます。
• 非標準の DOM メソッド SVGTransformList.getConsolidationMatrix() は削除されました。
• <svg> は長さ (length)　の変更にたいして「生きる」 (live) ようになりました。
• 可能な場合グループ透明度の計算が避けられるようになりました。"fill-opacity" か "stroke-opacity" の代わりに "opacity" が誤って使われた場合、速度が向上するはずです。
• ブラウザの最小フォントサイズの指定は、SVG テキストを台無し (mess up) にしないようになるでしょう。
• ペイントサーバの代替が実装されました。
• SVGPathSegList が完全に実装されました。
• <a> がネイティヴに実装され、より仕様に適合するようになりました。
• フィルタはドキュメントによって指定された通りに "linearRGB" か "sRGB" で演算できるようになりました。
• <switch> は SVGTransform 可能になりました。

Gran Paradiso Alpha 1 と SVG

Gran Paradiso Alpha 1 (別名 gecko 1.9a1) がリリースされました。 特に、ネイティブ SVG の大きなアップデートを含んでいます。 完全な書き直しという段階ではありませんが、コードの大部分が書き直されるか再構築されました。 あなたのコンテンツがこのバージョンでどのように動くのか、特に Firefox 1.5/2.0 からのリグレッションに気づくかどうか、非常に興味をもっています。 テストケースを添えてバグを報告してください。

1.5/2.0 からの主要な変更点:

• サポートされた新しい要素: <textPath> (FF2 にバックポートされました), <mask>, <pattern>, <filter>, <foreignObject>。
• 現在サポートされているフィルタ: <feComponentTransfer>, <feGaussianBlur>, <feMerge>, <feMorphology>, <feOffset>。
• 印刷ははるかに高品質になり、cairo が代替パスを使わない(cairo doesn't hit a fallback path)限りベクタベースになるでしょう。
• グループ透明度ははるかに高速です。
• テキストの DOM 関数がより多く実装され、既存のものも <textPath> 用に強化されました。
• 使われている新バージョンの cairo はより高速で、1.5/2.0 でみられたいくつかの問題を修正するでしょう。 しかし、新 Tessellator(平面分割ユニット)がランドする前のバージョンなので、パフォーマンスに問題のある SVG は依然として遅いままでしょう。
• OS X の cairo バックエンドは cairo-quartz から cairo-nquartz に切替えられました。はるかに高速でしょうが、十分にはテストされていません。 問題に出会ったらバグを報告してください。
• 塗りのロジックは交差している再描画が必要な領域(dirty region)のみを描画するようになり、動的な SVG や巨大な SVG のスクロールのパフォーマンスが改善されているでしょう。
• 仕様への準拠が通常どおり改善されました。
• コードがよりクリーンで、メンテナンスしやすく、メモリフットプリントより小さく、パフォーマンスが向上するよう再構築されました。

「なぜとても大きいのですか ?」

私達の実装に対する人々の疑問の1つは、なぜとても沢山のメモリを使うのかということです。Robert O'Callahan はこれに関して 1 つの意見をもち、私達は実際にそれらの幾つかを修正しています。最近パスデータの保存方法を変更しましたが、私は マッシーフ・ヒープ・プロファイラ【massif heap profiler】の valgrind を介して苛酷なケースを走らせ、興味深い幾つかのデータを得ることがでました。

問題になっているテストケースは Renesis の plan.svg で彼らの実装のデモに使われている 30MB の SVG ファイルです。Renesis は 50MB 程度を使用し 6 - 7 秒で読み込みます。デバッグビルドの mozilla は約 267MB を使用し 1 分 50 秒かかります。plan.svg の中身を調べて、解析するとこのようになります。

マッシーフ【massif】を通してこれを走らせた出力(私【原著作者 tor 氏】によって注釈が加えられています)は以下の通りです。これは bug 334999 によりパスデータの保存方法が変更されたビルド上でのものです。trunk ビルドは、おそらく「OTHER」に分類されたパスの保存方法に使われる小さいオブジェクトをもっているでしょう。 関連する HTML 出力ファイルはここで入手できます。

お分かりのように、最も大きいメモリユーザはストリングと一般的な属性データの関連データであるように見えます。しかし、それが使用している 60MB 以上は 30MB のファイルに対して過剰に見えます。ここで何が起こっているか確信しているわけではありません -- Gecko 専門家の意見を歓迎します。

glibc アロケータの値が本当に正しいなら、 malloc コントロールのオーバーヘッドのために損している約 25MB は深刻な問題のように見えます。それは私たちが過度の値を小さいオブジェクトに割り当てていることを示します。この中には SVG ベースタイプ【SVG base types】に変換されていないものもありそうですが、これを引き起こしているものをより良く処理することは良いことでしょう。

SVG Frame はかなりの量のメモリを取り、私たちが活発に削っているものの 1 つなので、グラフを評価する目的のためには当面それを無視することができます。

要素は正しい量のぶんだけ場所を取ります。 まれにしか使用されないフィールドのプロパティを使用することでいくらか削減できるかもしれません。

「なぜ 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 にダイレクトなライブラリが提供されるべきです。

Firefox 2 での textPath

本日 <svg:textPath> サポートが MOZILLA_1_8_BRANCH にチェックインされました(bug 327539)。これは深刻な問題がなければ Firefox 2 に登場することを意味しています。金曜日からの ブランチ nightly ビルド か、近く登場する Firefox 2 のアルファ版でそれを試すことができます。

ブランチの textPath サポートはロバート・ロングソン(Robert Longson)の行った SVG テキストモジュールの DOM メソッドを textPath が処理するように拡張した素晴らしい仕事をもっていません。私達はパスの上にテキストを描く能力はあなたのコンテンツに対して十分であるか、またそれを支援する DOM インターフェースも必要であるか、興味をもっています。

私たちはあなたのコンテンツのテスト結果を聞くことを熱望しています。特別な関心は Firefox 1.5.x に関連した SVG テキストサポートで見られるなんらかのリグレッション(退行バグ)です。

フィルタのパフォーマンス

ベクタ・グラフィックス・フォーマットにピクセル・レベルの効果が何をしているのか、人は不思議に思うかもしれませんが、 SVG は多くの異なるフィルタ効果を持っています。 現在 Mozilla SVG は trunk でフィルタのサブセットを実装しています(要素の現状ページ、日本語訳)。

非公式のベンチマーキングの精神で、ここに単純なテストの結果があります。 もう一度、すべての数字は同じマシンからで、時間の単位は秒です。 test1 はおそらく最も単純なフィルタ効果、色マッピングのテストです。 test2 はかなり大きいフットプリントをもった RGBA ガウスぼかしのテストです。 test3 は(私達がショートカットせず、完全に RGBA ぼかしをしている)アルファ・ガウスぼかし、そしてずらし、次に効果を結合することでドロップ・シャドウを実現しています。

これらの数字に驚かされていません、フィルタ・ピクセル操作は真っ正直に書かれ、まだそのコ ードを調整し最適化する努力が一切ないままです。