あかさたの最近の仕事
2007-11-10 13:56 :
dojo.gfx(dojo 0.4.3) が IE で遅い件について改善にトライした
ここしばらく、Kodougu の IE における高速化を行っていました。これまで、Kodougu の IE 対応は機能カバー率こそ 100% であるものの、速度は Firefox の 1/10 以下という非常に舐めた状態でした。機能カバー率は 50% 程度であるものの Opera 対応の方が実用性が高いかもしれません。
私が IE というものを分かっていないせいだろうと思っていたのですが、どうも調べれば調べるほど、dojo 0.4.3 の dojo.gfx が怪しいということになってきました。（dojo 1.0 が出た時点でやたら古いものを使うなって話ですが。）そこで、 dojo のどこが遅いのか調査してみることにしました。
続きを読む
Posted by あかさた（編集）
2007-08-24 00:29 :
Firefox の SVG でアンダーラインは表示されない
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
Posted by あかさた（編集）
2007-02-08 22:02 :
ブラウザをリロードしても JavaScript の更新が反映されないことがある
Kodougu の開発中に気になったのですが、ブラウザをリロードしても JavaScript の更新が反映されないことがあるようです。キャッシュが効いているのでしょう。
Rails では、javascript_include_tag メソッドを使うと、以下のように JavaScript のファイル名の後ろに数字（たぶん時間）を追加して展開してくれます。これだと、アクセスするたびに URL が変更されるため、ブラウザのキャッシュの影響を受けません。
[code: type="text/javascript">]
SVG では JavaScript のインクルードは xlink を使うため、Rails のヘルパーメソッドを使うことはできません。そこで、以下のように書いてみました。
[code: xlink:href="/javascripts/prototype.js?<%= Time.now.to_i %>" />]
これで、毎回更新が反映されるはず。
Posted by あかさた（編集）
2007-02-06 13:10 :
SVG と prototype.js を組み合わせて Ajax してみる
Kodougu では、SVG と prototype.js を組み合わせて使っています。組み合わせてみてわかったことですが、prototype.js の機能は一部使えなくなります。事情については、以下に書いてあります。
script.aculo.us を使って SVG や VML の要素を動かす
Ajax の機能は使えるので、その部分と便利関数を主に利用しています。以下、SVG に直接 JavaScript を埋め込む方式の場合の Ajax の例です。
Kodougu より：
[code: xmlns='http://www.w3.org/2000/svg'
xmlns:xlink="http://www.w3.org/1999/xlink" >
]
こんな感じ（”［］”は小文字に変換してください。）です。ただし、Updater は使えませんでした。今は、手動で Response として受け取った XML 要素を、SVG 内の要素と置き換えています。（Element.appendChild() などを活用しています。）
余力があったら、prototype.js を SVG 上で Updater が動作するように改造するかもしれません。
Posted by あかさた（編集）
2006-12-31 02:07 :
script.aculo.us を使って SVG や VML の要素を動かす
未踏がらみの話ですが、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 の方が遅いとかあったかもしれません。
ふー、疲れた。
Posted by あかさた（編集）
2006-12-10 16:27 :
どの技術を選択するか
Kodougu は Web 上で動作するモデリングツールです。今私が頭を悩ませているのは、クライアントにどの技術を選択するのかです。ざっくりと以下のような候補が考えられます。
・ JavaScript（VML or SVG）
・ Flash
・ JavaApplet
今の世の中の流れを考えれば、間違いなく JavaScript です。ただ、モデリングツールのようなアプリケーションを開発する場合、ベクトル形式の描画処理が必要になってきます。JavaScript の世界では、ベクトル形式の描画の決定的な方法が存在しないのです。ベクトル形式の描画用の技術としては、VML や SVG が存在していますが、これがめちゃくちゃブラウザ依存の世界で、とてもですがまじめに実装する気が起こりません。
Flash や JavaApplet は、モデリングツールに必要な機能はそろっているのですが、世の中の流れからは逆行しちゃいますし、ブラウザだけでモデリングができるという Kodougu の利点と若干相容れないことになってしまいます。
# それに私はあまりこれらが好きじゃないですし。
この辺の事情から Gliffy も Flash で実装されているんだと思うんですよね。はぁ、どうしたもんだろ。
ちなみに、未踏の提案では JavaScript と言っちゃったので、最終的には JavaScript で実装しちゃうのだと思います。クロスブラウザな設計にして、未踏の期間中は IE だけで動作って感じですかね。うーん・・・。
Posted by あかさた（編集）
2007-11-12 21:01 : dhrname
http://www.kodougu.net/p/kodougu/diagram/tool/1?profile=true
を、Firefox + Firebugで試してみましたが、
遅くなる原因は、dojoによる、vmlとsvgの要素のつくりすぎかと。
上の例では、図を動かすと、200個以上の要素をすべて消してから、また新たに要素を作り直しています。
Firebugだと、この作業に非常に時間がかかっています。
さらに、transform属性を書き換えると、一瞬で移動したので、描画性能は関係ありません。
Firefox+firebugで「ツール -> Firebug -> Inspect Element」を選択してみてください。
Firebugの情報は検索すればすぐに見つかります。
2007-11-12 22:01 : あかさた
コメントありがとうございます！
おっしゃるとおり、本質的な問題は要素の作成しすぎだと思います。ちょっと状況を整理します。
(1) そもそも VML 要素が多すぎる
(2) 操作のたびに全要素を再生成している
(3) dojo.gfx._creator.createObject() は IE と Firefox の間で 3 ～ 4 倍、createGroup に至っては 30 倍程度の速度差が出ている
(4) IE のレンダラーが遅いわけではない
(5) IE でも Firefox 程度のパフォーマンスが出てほしい
まず、(1) は、図を少数の path で記述すれば要素の生成コストを抑えることができます。回転がある（矢印の先端など）ので、どれくらい減らせるかは未知数ですが、それなりには減らせると考えています。(2) は、一つの操作が与える影響範囲を絞り込めていないため、今は手をつけていません。(3) は、IE のみ dojo の使用を取りやめることで、要素の生成コストは数分の一になりました。ただ、それでも IE と Firefox の間にはまだ速度差がかなりあります。（トータルなパフォーマンスでは 8 倍近いのですが、IE 向けコードから createGroup を排除できていないだけなので、最終的には小さな問題になるでしょう。）
(1) と (2) については、おいおい改善できる問題なので、「がんばれ、自分！」で済む問題と把握しています。ただ、dojo を使って同じ処理を実行したときに、IE と Firefox の間で速度差が 10 倍以上開くとなると、複雑な図になると結局「IE では使い物にならない」という話になってしまいそうで、手を焼いています。
dojo 1.0 で Silverlight を試してみるという方法もあるので、いただいた情報を参考にもう少し試行錯誤してみます。ありがとうございました。
2007-11-12 22:27 : dhrname
がんばってください。応援しています。