« 地デジ録画とか | メイン | WILLCOM03いじり »
2009年12月16日
VisualC#でグラフ描画
小坂大先生の指導を仰ぐ。
VisualC#でのグラフ描画を、データ受信のスレッド内に入れるのは、やはり無謀。
データ受信スレッドでデータを保存しておき、
別スレッド、例えばタイマ等で、そのデータのグラフ描画を行うべき、とのこと。
ヒビマイシン。
投稿者 akita : 2009年12月16日 15:29
コメント
C#ってイベントでアクションを励起するんですよね?
データ受信スレッドで、
バッファフルイベントを発生させればいいのでは??
投稿者 imuno : 2009年12月18日 14:06
ふむ?バッファフルイベント?
データ受信スレッド→バッファがいっぱいになったときに呼ばれる関数、です
(言葉が間違ってましたね、スレッドじゃないや)
その関数内で画面描画もさせる(PAINTイベントを発生させる)のは無謀だった、という話でした。
投稿者 akita : 2009年12月18日 16:05
そういう話を聞くと、
構造はQtの方が美しいなぁ…。
>データ受信スレッド→バッファがいっぱいになったときに呼ばれる関数、です
つまり、バッファフルイベントで励起された関数、
ということですね。
同一の関数では同一スレッドを使用するので、
やはり描画は別スレッドで行う必要があるのでしょう。
ちなみに、
Qt4ではスレッド分けを開発者がそこまで意識せずに、
シグナル・スロット構造でイベントを処理させることができます。
Qt4.6では状態機械から設計を行うことができるので、
イベントなどをかなり効率よく設計できますよ。
投稿者 imuno : 2009年12月21日 10:39
うーむ。プログラミング言語的には、そうなんでしょうが、肝心のUSBマイコンの通信ライブラリをつつく方法が見当たらず。
投稿者 akita : 2009年12月21日 22:37
QtはGUIのツールキットでC++で書かれていますが、C#などからでも利用することができますよ。僕はPythonとQtの組み合わせで一時期愛用していました。
まぁ、グラフ描画のためにマルチスレッドにするプログラムは難しくないですから、わざわざQtを採用する理由はないですが...
投稿者 まつむら : 2009年12月22日 09:38
ふむふむ?なるほど。完全に誤解をしていました。
GUIのツールキットですか。ああ、GTK+みたいな感じのものですかね。
投稿者 akita : 2009年12月22日 10:55