Metasequoia BBS

[2424] Ver3.1 Beta3 / O.Mizno

Beta3での変更点ですが、インポートプラグインから利用できるよう変更点がいくつかあります。

Create***UserData()のプラグインIDに常駐型・コマンドプラグイン以外のものを指定した場合、
プラグインがアンロードされた後もユーザーデータが保持されるようになりました。
ドキュメントが破棄されるか、明示的にDelete***UserData()を呼ぶまでは削除されません。
例えばインポートプラグインからCreate***UserData()を呼び出す場合、
ホストとなる常駐型プラグインのIDを指定して管理を委ねるか、
自身のIDを指定して管理者がいない状態で使用するかのどちらかとなります。

また、Create***UserData()に識別子として任意文字列も指定するようになりました。
実際にはプラグインIDとセットで判別されるので、例えば"Weight"のようなありがちな識別子を指定しても
他のプラグインとはIDが異なるので、重複ではなく別データ扱いになります。
同じIDと識別子で呼び出された場合は、新規作成ではなく既存のユーザーデータIDを返すように変更になりました。
生成せずに既に存在するかだけを調べるFind***UserData()も追加されたので、
これでインポートプラグイン・常駐プラグインのどちらでCreate***UserData()を呼びだしても、
同じように扱うことが出来ると思います。
インポートプラグインでユーザーデータを先に用意しておき、常駐プラグインのOnNewDocumentが呼ばれたら
ユーザーデータがあるかどうか調べて適切に処理することができるかと思います。

2012-06-15 17:15

[2428] Re: Ver3.1 Beta3 / sio29

Response

対応ありがとうごさいます。

ところでオブジェクトのユーザーデータ獲得においてコピーではなくポインタを返すのは難しいでしょうか?
構造体が大きい場合、フラグなどのちょっとした値の参照をする場合にも全コピーでは動作が重い気がします。

2012-06-15 19:40

[2429] Re: Re: Ver3.1 Beta3 / O.Mizno

Response

ポインタを渡した直後に読み書きするなら問題ないのですが、
リサイズなどでメモリの再配置が行われた後に古いポインタでアクセスしてしまう恐れがあるので、
安全性を重視して今の仕様にしています。
速度は実際に測った訳ではないですが、10万頂点×数十byte=数MB程度と考えると、
それほど大した負荷でもないようには思います。

2012-06-15 22:34

[2430] Re: Re: Re: Ver3.1 Beta3 / sio29

Response

いえそういう使い方ではなく、構造体の中のちょっとしたフラグを参照するのに全コピーはいかがなものかと。
ポインタを返すのが怖いのならば部分コピーを出来るようにするとかはどうでしょう?

2012-06-15 23:24

[2431] Re: Re: Re: Re: Ver3.1 Beta3 / O.Mizno

Response

そういうことでしたか。
まあ確かにその通りなのですが、APIの仕様を必要以上に複雑にしたくはないというのと、
実際どれくらいのボトルネックになるのかが読みづらいものがあるので、
速度面の問題が顕在化してから対応を検討するのでも遅くはない気がします。

まだ解決していない頂点間のデータ補間のほうでも格納方法など検討する必要があるので、
とりあえずは今の仕様のままで進めてみてください。

2012-06-16 10:07

[2603] Re: Re: Re: Re: Ver3.1 Beta3 / O.Mizno

Response

>いえそういう使い方ではなく、構造体の中のちょっとしたフラグを参照するのに全コピーはいかがなものかと。
>ポインタを返すのが怖いのならば部分コピーを出来るようにするとかはどうでしょう?

Beta5で開始オフセットから指定バイト数をコピーするGet/SetUserDataPartを追加しました。
ただ関数呼び出し自体のボトルネックがそれなりにあるので、
部分コピーによる速度面での恩恵はさほどないかもしれませんが。
（実際に速度を測ってはいないのでどの程度かはわかっていません）

2012-09-08 12:20

[2605] Re: Re: Re: Re: Re: Ver3.1 Beta3 / sio29

Response

対応ありがとうございます。
オブジェクトなどに付随するデータは大きくなるので意味はあると思います。
ただ今作っているものはすでに複数のユーザーデータを使うことで対応してしまったので、今から作り直すかは微妙ですが…
ただし今後は構造体をアクセスし易いデータごとに複数のユーザーデータに分けるという面倒な作業がなくなるので、ありがたいです。

2012-09-09 20:31

[2661] Re: Ver3.1 Beta3 / mqdl

Response

現在 GetVertexUserData で、SetVertexUserData 未実施の場合
不定値が返りますが、不定値ではなく例えばゼロクリアした領域などに
出来ませんでしょうか。

例えば下記の tag の値に -1 を事前に設定していた場合

int tag;
obj->GetVertexUserData(ID\x2c vert\x2c &tag);

事前に設定している -1か、不定値で-1になっているのか不明ですと困ります。
ゼロクリアした領域が必要な訳ではなく、事前設定か不定値かの
判別をしたいと言うのが目的です。

2012-09-19 22:23

[2662] Re: Re: Ver3.1 Beta3 / O.Mizno

Response

>現在 GetVertexUserData で、SetVertexUserData 未実施の場合
>不定値が返りますが、不定値ではなく例えばゼロクリアした領域などに
>出来ませんでしょうか。

ドキュメントには不定値と記載しているのですが、実際にはゼロでクリアしています。
別にSetされたかどうかのフラグを持つと１バイト浪費してしまうので、
最終仕様としてこのままにして、ドキュメントの記載のほうを変更しようと思っていますが、
ゼロクリアがされている前提で現状何か問題がありますか？
対応漏れでゼロクリアできていないケースが残っている可能性はあり得ます。

2012-09-20 16:23

[2663] Re: Re: Re: Ver3.1 Beta3 / mqdl

Response

ご連絡ありがとうございます。

テスト用に下記の通り簡単なソースをOnNewDocumentで呼んでみました。
ゼロクリア済みとの事でしたが、不定値が返ってきます。

　VUD_TAG = doc->CreateVertexUserData(0xbd1224db\x2c 0x000000c2\x2c "testtag"\x2c sizeof(BYTE));

　for(int i = 0; i < doc->GetObjectCount(); i++)
　{
　　MQObject obj = doc->GetObject(i);
　　obj->AllocVertexUserData(VUD_TAG);
　　
　　for(int vert = 0; vert < obj->GetVertexCount(); vert++)
　　{
　　　BYTE tag;
　　　if(obj->GetVertexUserData(VUD_TAG\x2c vert\x2c &tag))
　　　　ATLTRACE("found %d\n"\x2c(int)tag);//ゼロ以外が返ります
　　　else
　　　　ATLTRACE("not found\n");
　　　}

2012-09-20 19:45

[2666] Re: Re: Re: Re: Ver3.1 Beta3 / O.Mizno

Response

頂点を追加したときはゼロクリアされるのですが、
既に頂点がある状態でallocしたときにクリアし忘れているようですね・・・
単なる不具合のようなものなので、次の更新で修正します。

2012-09-20 23:29

[2751] Re: Re: Re: Re: Ver3.1 Beta3 / Administrator

Response

Beta7でalloc時にゼロクリアされるようにしました。
SDK自体は変更ありません。

2012-10-12 16:16

[2784] Re: Re: Re: Re: Re: Ver3.1 Beta3 / mqdl

Response

>Beta7でalloc時にゼロクリアされるようにしました。
>SDK自体は変更ありません。

確認させていただきました。
ゼロクリアされている様でした。
ご対応ありがとうございました。

2012-10-17 21:17