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-03-23 12:24 :
Kodougu の表示が IE7 でおかしくなる
Kodougu の表示が IE7 でおかしくなることを確認しました。IE6 では表示されるのに。orz
IE7 になって HTML のレンダリングエンジンが新しくなったらしく、このブログでも細かいところが、表示されなくなっています。Web アプリとしては、IE6 と IE7 を別物のブラウザとして考えて実装せよってことですかね。。。大変な世界だ。
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-18 06:40 :
描画方法を考える
私にしては珍しく、朝早く（5時くらい）起きてしまいました・・・。
さっくりと VML（Vector Markup Language）を調査しました。SVG から調べていない理由としては、とりあえず IE で動かそうという気になったということもありますが、実は仕様書が VML の方が読みやすかったからだったりします。(^^;
VML は SGML をベースにした言語みたいです。したがって、ぱっと見 HTML に近いですし、レイアウトには CSS を使ったりします。まだ試していませんが、HTML に埋め込むと、JavaScript を使って DOM にアクセスできるみたいなので、prototype.js とかで Ajax で更新とかもできそうです。Kodougu でもうまく実装すれば JavaScript の Code をほとんど書かずに済むかも・・・。
（実装方針としては、サーバーで VML/SVG を出力して、JavaScript では Event 処理だけを記述する感じです。）
おや、Google Maps でも VML がかなり使われているらしいです。
http://eto.com/d/0503.html#VML
Posted by あかさた（編集）
2006-12-18 06:37 :
Canvas を VML で実装したものがあるらしい（ExplorerCanvas）
VML を調べてて脱線。Canvas を VML で実装したものを発見しました。
ExplorerCanvas（Apache License V2.0）
http://sourceforge.net/projects/excanvas/
（via. Taken SPC）
使えるかなぁ・・・？
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
がんばってください。応援しています。