もきもき3D

アクセスカウンタ

zoom RSS 選択処理の速度

<<   作成日時 : 2007/11/30 00:08   >>

ブログ気持玉 0 / トラックバック 0 / コメント 0

 選択状態に対して任意の選択個所のみを解除するような場合、edit->typeSelect(〜,FALSE)で順次選択解除するよりも、事前に非解除対象IDを待避した後にexecute(SEL_typeでCLEAR)してからedit->typeSelect(〜,TRUE)で選択し直した方が速く済むっぽい。
 視覚的にもバタツキというか間延びが無い(速いのだから当然と言えば当然だけど)。

 特定の一連処理では前者が0.047秒、後者が0.016秒だった。
 まぁ、コード自体が多少変わるから、数値だけ見れば誤差範囲だと言い張る事も可能だろうけど。
 内容は条件判定し、解除対象なら随時選択解除する、または、解除対象でないIDを配列に待避して後に選択処理する、であるから後者の方が冗長。

 editBegin(〜,OPSEL_|OPSEL_MODIFY)に対してdone(〜,EDERR_NONE,〜)で確定するに際して、typeSelect(〜,TRUE)よりも(〜,FALSE)の方が内部での処理コストが高いとかあるのかしらん。

----
 あ〜対象データを増やして、残選択数と解除数を同じに揃えたらほぼ同じ時間になった(;・з・)
 128ポリ(64:64)で共に0.47。 掛かる時間の上限が増えてないってのはあれだけど(・з・)
 最初に適当なデータ72ポリ(残20:解52)を使ったのは失敗だったか。 比で考えれば比に応じた時間になってるね。
 でも、SEL_(CLEAR)使った方が視覚的に綺麗なんだよなぁ(LSで書いたSEL(CLEAR)→(SET,ID)と同じ感じだった)。
 ただ、その場合、残選択が多い時の速度低下がどの程度出てくるのか・・・('A`)ムゥ
 デロデロデロっと解除されていくのが見えるのがいいか、選択されていくのが見えるのがいいのか、そこが実際の選択分岐点かもしれぬ。

 あ、もやしもん始まった(゜∀゜)

----
 気になったから全ポリを順に選択&順に解除するだけのものを書いてみた。
 どちらも4000ポリ程度ではclock()で取れない程の短時間で処理される模様。
 9000ポリ程度の球に試してみたらOSが落ちた(w

 遅く感じるのはビデオに対する描画(GL)コマンドがバッファリングされるとか、そういう面の問題なのかも。
 個別選択処理だと律儀にその回数分のコマンドを発行するけど、SEL_(CLEAR)だと一回のコマンドで済むから早く済む、と。
 ただ、視覚的にバタツキが出るのが難点か。
 で、9000ポリの時は連続して高速に大量の描画コマンドを送られてビデオカードがパンクしたんじゃないかと(w
 場合によっては大量の選択処理を扱う場合はそこらへんも考えて最小の描画コマンドになるようにしないとやばいかも?
 まぁ、単に数日に渡る連続稼動で何かしらの綻びが出てただけかもしれないけど。
 ちなみに9のGLSLは描画が遅かった(・з・)

テーマ

関連テーマ 一覧


月別リンク

ブログ気持玉

クリックして気持ちを伝えよう!
ログインしてクリックすれば、自分のブログへのリンクが付きます。
→ログインへ

トラックバック(0件)

タイトル (本文) ブログ名/日時

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(0件)

内 容 ニックネーム/日時

コメントする help

ニックネーム
本 文
選択処理の速度 もきもき3D/BIGLOBEウェブリブログ
文字サイズ:       閉じる