ここしばらく、Kodougu の IE における高速化を行っていました。これまで、Kodougu の IE 対応は機能カバー率こそ 100% であるものの、速度は Firefox の 1/10 以下という非常に舐めた状態でした。機能カバー率は 50% 程度であるものの Opera 対応の方が実用性が高いかもしれません。

私が IE というものを分かっていないせいだろうと思っていたのですが、どうも調べれば調べるほど、dojo 0.4.3 の dojo.gfx が怪しいということになってきました。（dojo 1.0 が出た時点でやたら古いものを使うなって話ですが。）そこで、 dojo のどこが遅いのか調査してみることにしました。

続きを読む

Firefox の SVG 実装の text 要素では、text-decoration が無視されるそうです。この結果、テキストの下にアンダーラインなどを表示することができません。困った・・・。バグというよりは、現時点では仕様っぽいですが。Firefox は SVG 実装が本気なのかそうでないのかよくわからないので、判断に苦しみます。

Kodougu でオブジェクト図を実装する場合どうしたらいいんだ？？？　Opera とかだと、SVG 実装はかなり本気みたいで、そういうこともないのですが・・・。

現象的には軽微な気がするので、すぐに対応できそうなところを対応していないということは、何か根本的な問題を抱えているということですかね。うーん・・・。

詳細は以下を参照してください。

SVG/対応状況 - Mozilla Firefox まとめサイト
http://firefox.geckodev.org/index.php?SVG%2F%E5%AF%BE%E5%BF%9C%E7%8A%B6%E6%B3%81

Bug 317196 – text-decoration broken: no underline, line thru, etc
https://bugzilla.mozilla.org/show_bug.cgi?id=317196

Kodougu の開発中に気になったのですが、ブラウザをリロードしても JavaScript の更新が反映されないことがあるようです。キャッシュが効いているのでしょう。

Rails では、javascript_include_tag メソッドを使うと、以下のように JavaScript のファイル名の後ろに数字（たぶん時間）を追加して展開してくれます。これだと、アクセスするたびに URL が変更されるため、ブラウザのキャッシュの影響を受けません。

[code: ]

SVG では JavaScript のインクルードは xlink を使うため、Rails のヘルパーメソッドを使うことはできません。そこで、以下のように書いてみました。

[code: 









]

こんな感じ（”［］”は小文字に変換してください。）です。ただし、Updater は使えませんでした。今は、手動で Response として受け取った XML 要素を、SVG 内の要素と置き換えています。（Element.appendChild() などを活用しています。）

余力があったら、prototype.js を SVG 上で Updater が動作するように改造するかもしれません。

未踏がらみの話ですが、JavaScript を使って、ブラウザ上で VML や SVG を使って描画した要素をマウスで動かすということをしたかったので、調査してみました。結論を言えば、JavaScript で要素を動かすことはできました。ただ、JavaScript のコードを大量に書くと、クロスブラウザの問題などで手間がかかりそうなので、一歩踏み込んで script.aculo.us を使って楽をできないか試してみました。

実験としては、script.aculo.us の Draggable を使って、ブラウザ上で VML や SVG を使って描画した要素をマウスで動かすということをしてみました。

結論を言うと、VML はいけますが、SVG はいけませんでした。ちゃんとソースコードを読んだわけではないのですが、script.aculo.us の Draggable はスタイルシートの left や top を操作します。VML はこれで位置座標を変更できるのですが、SVG の Rect 要素などは、位置をスタイルシートで設定するわけではなく、x や y などの属性で位置を操作するためできません。script.aculo.us の Draggable をそういう風に書き換えれば動作するのだと思いますが、ソースを読むのもしんどいので、結局 SVG 向けには自前で Draggable 的なものを作成しました。

以下、例です。
■ VML（IE6 で動作確認済み）
○ VML

○ JavaScript（script.aculo.us）

new Draggable("vml_rect")

○ サンプル（VML）
IE だけですが、四角が表示されると思いますので、自由にドラッグしてください。


■ SVG（FireFox 1.5 以降で動作確認済み）
こちらは、script.aculo.us を使わずに自力で ECMAScript（JavaScript）をたたいて、SVG に埋め込んでいます。

※ IE では動作しません。

■ パフォーマンス
VML + script.aculo.us よりも SVG + ECMAScript の方が動作が軽いです。というか、かなりの差があります。調査していませんが以下のような原因が考えられます。

・ script.aculo.us のせい
script.aculo.us では、要素を半透明にしたりしています。

・ 環境依存
私の PC でだけパフォーマンスの差が出ているのかもしれません。（WinXP + IE6 + Pen4 2.8GHz + Mem 1GB + Geforce2 MX）

・ JavaScript エンジンの速度の差
もしかすると、スクリプトは IE の方が遅いとかあったかもしれません。

ふー、疲れた。

Kodougu は Web 上で動作するモデリングツールです。今私が頭を悩ませているのは、クライアントにどの技術を選択するのかです。ざっくりと以下のような候補が考えられます。
・ JavaScript（VML or SVG）
・ Flash
・ JavaApplet

今の世の中の流れを考えれば、間違いなく JavaScript です。ただ、モデリングツールのようなアプリケーションを開発する場合、ベクトル形式の描画処理が必要になってきます。JavaScript の世界では、ベクトル形式の描画の決定的な方法が存在しないのです。ベクトル形式の描画用の技術としては、VML や SVG が存在していますが、これがめちゃくちゃブラウザ依存の世界で、とてもですがまじめに実装する気が起こりません。

Flash や JavaApplet は、モデリングツールに必要な機能はそろっているのですが、世の中の流れからは逆行しちゃいますし、ブラウザだけでモデリングができるという Kodougu の利点と若干相容れないことになってしまいます。
# それに私はあまりこれらが好きじゃないですし。

この辺の事情から Gliffy も Flash で実装されているんだと思うんですよね。はぁ、どうしたもんだろ。

ちなみに、未踏の提案では JavaScript と言っちゃったので、最終的には JavaScript で実装しちゃうのだと思います。クロスブラウザな設計にして、未踏の期間中は IE だけで動作って感じですかね。うーん・・・。