Cube コアメモ

タスクシステム

　ネイティブスレッドでの検証と、OSC2009 Shimane でお話したシングルスレッドでも効果が見込めるラウンドトリップタイムや非同期ファイルアクセス時間の活用の検証が終わっとらん。ふっと思ったんじゃけど、 RTT の検証に関しては、 Ruby や C++ 単独で検証するより、コルーチンのある組み込み言語を C++ に組み込んだ方が検証早いかもしれん。

新レンダリング機構 (1)

　やっぱレンダーシステムを直接取得して操作するより、オペレーション（コマンド）オブジェクトを投げる方式にした方が無難。それをレンダーシステムの操作に隠蔽するアイデアを前に書いたが、そしたら render() がコールされるまで、複数の API コールに渡ってロックかまさにゃいけんけぇ現実的じゃない。実行部を並列化する意味がのうなる。

　またこれも OSC で言うたけど、描画は並列化できるけえ終わったタスクからコマンドオブジェクトを投げる形に持ってきたい。やっぱ検証プラットフォームいるわコレ……

新レンダリング機構 (2)

　前にちょっと書いた、エンドユーザーが本来使用できんプレースホルダーを使用したとき、レンダリングパイプラインをキャンセルして、該当のプログラムをタスクに追加して次の機会に再度レンダリングをかける機能。個人的に今一番欲しい機能（コンパネからブロックやモジュールを配置して、テンプレートに配置情報を書くんじゃのうて、テンプレートに書いたら後は全自動でやってほしい）。

　メッセージング機構の実装が必須。

メッセージング

　操作対象のオブジェクトのポインタを掴んで、メソッドを叩くんじゃのうて、メインシステムのメッセージセンターにメッセージを送信して副作用を期待する原子的な（単方向）通信機構。デリゲートに似ちょると思う人もおってかもしれんけど、あれは間接ジャンプの一種じゃし、これは関数コールではないけん非同期になる。タスクシステム以上に一般的な技術で、 Nuke との相性も間違いなく高い。*1

仮想サービス

　修正にあたり mumincacao さんに丸投げする野望を秘めちょったけど、忙しいらしいけん、設計をもう一度考える。 XCDGJ あたりでヒアリングするかもしれんけんそのときはよろしくです。

*1:ちゅーか Nuke はもともとアドオンの独立性、順不同実行が意識されとるけえ、一般にスレッディングで使われる技術とはぜんぶ相性がいい