« のどが痛い | メイン | KS3進捗 »

2007年02月18日

.NETあれこれ

目下のところKSynth3を開発中なわけだが
UI部分を.NETコントロールを用いたシステムにすることは前にかいた。
シンセプログラムには欠かせないボリュームコントロールなどの
独自コントロールを作ることが比較的容易に行えるからだ。
しかしこの.NETフレームワークがおもわぬ問題に・・・。

問題1:コントロールのバグがすべてを巻き込む!?
独自コントロールを作れるのは良いが、独自コントロールがバグってると
そのあおりをくって、独自コントロールをホストしているフォームもバグる。
(VSのUIデザイナでホストしているフォームが編集負荷になる。)
これはVSの痛い仕様だ。しかたなく、VSが生成したコードレベルでの編集を余儀なくされる。
しかも、独自コントロールがみためにバグっていればなんのことはないが
よくわからないコントロールの初期化のところで死んでいるのでお手上げである。
(なんとなく私が読み込ませている画像リソースがあやしいが・・・)
結局この問題は、そこまで作っていたコントロールを捨てて
新しいコントロールを再度作成することで解決した。

問題2:共通言語ランタイム遅いよ!
.NETフレームワークは共通言語ランタイムといわれるものに対応していて
いわゆるマネージドなコードである必要がある。
しかし、マネージドなコードだといままでのネイティブ(アンマネージド)な
ライブラリとの互換性が無いので、ネイティブで動作するアプリのUI部分だけを
.NETフレームワークで作るには問題がある。そこでVS2005からアンマネージドな
コードを許可するというコンパイラオプションが追加された。(/clrである)
とりあえず、このオプションを有効にしていれば.NETフレームワークを使っていようが
Win32APIもなんでもよべてしまう。
この方法で.NETのUI部分のプログラムでKSynth3を操作するコードをかいてたら
なぜかやたらwaveレンダリングが重い。というか処理落ちしてる。
UI作成前にレンダリングしてたときはそれほど重くなかったのに。
まさかとは思い、プロジェクトをわけてスタティックLIBでエンジン部分のコードを
吐き出してみた。/clrしているUIプログラム側でリンク。
するとまったく処理オチしないじゃないか!!
まさか中間言語で走ってるから遅いのか?どっかで最適化されてるとか聞いた気が
するのは幻想だったのか・・・。
ちゃんと理由をしらべてないが、/clrでアンマネージドコードがかけるからって
いままでネイティブで高速に動作していたやつを一緒にコンパイルしてはならない。


というわけで、
KSynth3の開発がなかなか進行しねー

投稿者 kioku : 2007年02月18日 07:20