西尾泰和のブログ

GRINEditの中で一番重たい関数は反発力を計算している PL_Repulsion#applyなのだけど、ちょっと眺めて、ループの奥でやっている割り算が 定数での割り算なのであらかじめ逆数を求めて置いて掛け算するようにしたら5%早くなった。 そこで火が付いて、毎回頂点をIMassPointにキャストしてgetPositionしてたのを 先にキャストとgetPositionをすませて配列に入れておくようにしたら元の半分の時間に減った。 あとベクトルの計算を不定長のベクトルと見なしてforで回して計算していたのを、 長さ2のベクトル決めうちにしてインライン展開したら、元の実行時間の7%に縮んだ。 プロファイラ上のもたもたした画面で見ると早くなったのが実感でわかる。 まぁ、プロファイラをかけていることで、関数呼び出しのオーバーヘッドが増えているはずなので、 インライン展開による高速化の度合いは誇張されているだろう。 この高速化のせいで、反発力計算クラスはそのままでは3次元に対応できなくなったけど、 対応させるさほど難しくないし、その見返りとしてプログラム全体で見て30%の高速化になったのだったら 悪くない取引だと思う。

1746頂点の「全ての辺が8本のグラフ」の描画が5FPS以上で動く！ 実用的な速度で動かないグラフの例として入れたのに、ぎりぎり実用範囲内に入ってしまった。

物理法則を設計する上で大事なこと。 まず力が連続的に変化すること。 次に作用反作用の法則を入れること。 最後に、現実の物理法則はあり得る物理法則の一つに過ぎないので、 物理学的に正しい物理法則ではなく、得たい結果が得られる物理法則を選ぶべき。 この3つだろうか。 最初の項はちょっと正しくなくて、例えば壁に貼り付く物理法則の場合、 一定距離に近づくと急に力が発生するから連続的ではない。 だから正確に言うと「適切な長さの切り替え区間を挟まずに プラスの力とマイナスの力を切り替えてはいけない」 ということになるだろうか。 要するに「0以上はマイナス1、0未満はプラス1」なんて力は 0周辺で振動を起こすのでダメだということ。 たまに1ピクセル以上の振動を起こすソフトがあるけど、 それは物理演算の設計のミスだろう。 作用反作用がないと合計が0にならずに1方向に動いていってしまう。 例外はやっぱり壁に対する力で、壁は力を吸収しても自然に見える。 最後の物理法則は自由にデザインしてもいいという宣言は重要で、 GRINEditの反発力なんか半径の二乗分の一どころか、半径分の一でもない。 なぜかというと、うっかりこんな実装にしたら、 運悪くすごく近い位置に頂点が並んだが最後、画面の果てのそのまた果てまで吹き飛んでしまう。

プラグインシステムのおかげで新しい頂点や物理法則の実装が楽になったかも。 プラグインフォルダのinit.pyは自動的に発見されて実行されるので、 新しい何かを実装しようと思ったらまずtestフォルダの中にinit.pyを作る。 そしてそこで頂点や辺や物理法則をグラフに追加するコードを書く。 実行すると実装中の頂点とかが表示される。 でJavaのコードを修正して実行して、とやって完成したら、 そのinit.pyをtestFileIconVertex.pyとかに名前変更する。 そうするともう呼び出されなくなるけど、テストフォルダの中に テスト用のスクリプトが入っていることになる。 そのままにしていてもいいし、Jythonでその「新しい頂点」の機能を試すための 簡単なサンプルとしてsampleフォルダに移して置いてもいい。

新しいフローレイアウト用の物理法則を追加。今は強さ決めうちの方向も上下決めうちだけど、手で書いたちっちゃいツリーはちゃんと整形された。明日はもっと大きいツリーや、合流のある例、ループのある例を作ってテストだ。

By 西尾泰和 at 2006-11-18 23:26:49 | この記事へのリンクはこちらへ(パーマリンク)
フィードバック (0) | トラックバック (0)

SWTで拡張子からアイコン画像を取得し。それをAWTのImageに変換して2倍に拡大してから描画しました。ファイルをドラッグドロップしたらこの頂点ができて、ダブルクリックしたらファイルが開く、というのを作りたいのだけど、とりあえずアイコンを描画するところまで。でも残りはさほど難しくない気もする。

問題はマウスハンドラかなぁ。 今は「右ボタンのイベントを処理するハンドラ」「左ボタンのイベントを処理するハンドラ」という二つがあり、そこにMouseOperationクラスのインスタンスを入れる形になっている。でも、逆に言うとその二つしか登録できない。 以前、拡大縮小と平行移動が別のクラスで実装されていて、いちいち切り替えないといけないのが面倒だったので、Shiftキーが押されているかどうかで挙動の変わるものを作ったけど、いまいち納得がいかなかった。それはこういうこと。「右ドラッグ」と「Shiftを押された右ドラッグ」は競合しないものだから、それぞれを取るハンドラを両方同時にアクティブにしてあっても問題は起きない。それなのに「右マウス用ハンドラ」と「左マウス用ハンドラ」の2つしかハンドラを入れる場所がない。現状のまま「ダブルクリック」というドラッグと競合しないイベントを取るハンドラを追加したとしても、また抱き合わせクラスを作るか、さもなくば「ハンドラを切り替えてからダブルクリック」とやるかしかない。これはどう考えてもイベント分配システムの設計が間違っている。

By 西尾泰和 at 2006-11-18 19:23:20 | この記事へのリンクはこちらへ(パーマリンク)
フィードバック (0) | トラックバック (0)

By 西尾泰和 at 2006-11-13 21:17:01 | この記事へのリンクはこちらへ(パーマリンク)
フィードバック (0) | トラックバック (0)

grinedit.addVertex("BoxVertex", {})

BoxVertexの所を org.nishiohirokazu.graph.FileVertex に変えてみる。 Graph#addObjでキャストエラー。IGRINObjectインターフェイスをimplementsしていないから。 ちなみに今回はRenderableVertexを継承していないのだ。 なぜならextends JLabelだから。

	private String id;
	public String getId() {
		return id;
	}

	public void setId(Object o){
		id = o.toString();
	}

	public Hashtable getParams() {
		return new Hashtable();
	}

SimpleLayout#layoutStepでキャストエラー。 MassPointを継承していないから。これはIMassPointに変えるべきですな。 IMassPointをimplementsしてMassPointを参考に実装。

	private Vector dVelList = new Vector();
	private double[] position = new double[2];
	private double[] velocity = new double[2];

	public Vector getDVelList() {
		return dVelList;
	}

	public void setDVelList(Vector velList) {
		dVelList = velList;
	}

	public double[] getPosition() {
		return position;
	}

	public void setPosition(double[] position) {
		this.position = position;
	}

	public double[] getVelocity() {
		return velocity;
	}

	public void setVelocity(double[] velocity) {
		this.velocity = velocity;
	}

PL_RepulsionでRenderableVertexにキャストしようとしてエラー。 これはRepulsionが悪い。 IMassPointに変更。

ワールド座標系からスクリーン座標系に変換するところで RenderableVertexにキャストしていたのを、

Object o = i.next();
IMassPoint v = (IMassPoint) o;
IHasScreenPos sv = (IHasScreenPos) o;
sv.setScreenPos(vp.viewportTransform(v.getPosition()));

private double[] screenPos;
public double[] getScreenPos() {
	return screenPos;
}
public void setScreenPos(double[] pos) {
	screenPos = pos;
}

レンダリングエンジンがIRenderにキャストしようとするのでそれもimplements

public void render(Object target) {
	update((Graphics) target);
}

By 西尾泰和 at 2006-11-13 21:07:24 | この記事へのリンクはこちらへ(パーマリンク)
フィードバック (0) | トラックバック (0)

VERTEX
3
1	Hello
2	GRINEdit
EDGE
1	2
2	3

legacyFormatは簡単なグラフを作る上では楽に書けるので、 今後のバージョンでも(非推奨ながら)残していこうと思っています。 しかし、頂点の色など色々とカスタマイズをしようとすると、 タブ区切りの現状ではどんどん泥沼にはまっていきます。 それを解決するためにYAMLベースで作った新しいフォーマットが 今後のリリースでは「標準のフォーマット」という位置づけになる予定です。

Vertex: 
  v1: {label: Hello}
  v2: {label: GRINEdit}
  v3: {}
Edge: 
  e1: [v1, v2]
  e2: [v2, v3]

By 西尾泰和 at 2006-11-13 15:33:33 | この記事へのリンクはこちらへ(パーマリンク)
フィードバック (0) | トラックバック (0)