- 1 名前：デフォルトの名無しさん mailto:sage [2009/04/01(水) 10:15:52 ]
- (#ﾟーﾟ)つ ＜ C#、.NETの話題はこちらでどうぞ。
前スレ
C#, C♯, C#相談室 Part51
pc12.2ch.net/test/read.cgi/tech/1233757615/
Visual C# 2008 Express Edition 日本語版
www.microsoft.com/japan/msdn/vstudio/express/vcsharp/
その他テンプレ>>2-5くらい
- 94 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 20:54:33 ]
- >>91-93さん
レスありがとうございます
WebBrowser.Document.All.GetElementsByName("id")[0].SetAttribute( "Value", "name" );
のように入力してログインまで持って行きたいんですが
>>92
正確ではありませんでした
すみません
DOM解析済みのHTMLでFrameを取りに行ってるみたいなんで無理みたいですorz
WebBrowserコントロールからフレームを利用したのページのHTMLソース取得方法
ttp://social.msdn.microsoft.com/Forums/ja-JP/vsgeneralja/thread/41e23caf-05d6-4dff-b5a1-9b1ecb12b4ed/
- 95 名前：デフォルトの名無しさん mailto:sage [2009/04/06(月) 22:15:40 ]
- >>94
がんばればできる。
- 96 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 14:17:00 ]
- 現在大体100μs単位で動くタイマーを作成しているのですが、別スレッドからControl.BeginInvokeでコントロールを
操作する際に、そこでApplication.DoEvensを実行すると、コントロールが壊れる?みたいなのですが、なぜでしょうか?
具体的にいうと、別スレッドでビジーループを回して待機していたタイマーからイベントが飛び、Control.BeginInvokeで
メインスレッドにて登録されたデリゲートを実行するようになっており、デリゲート内にApplication.DoEventsがあると、
別ウインドウで操作していたHScrollBarが壊れ、Dock.FillしていたはずのコントロールがHScrollBar部分をドラッグ
することによりリサイズできてしまう、という具合です。
サンプルプロジェクト:
ttp://www1.axfc.net/uploader/He/so/214358
pass: invoke
サンプルプロジェクトのProcessingWindowのStartボタンをクリックした後、ControlWindowのスクロールバー右を
連打するとスクロールバーが壊れます。
一応メインスレッド上でタイマーのビジーループを回すか、Application.DoEventsを取り除くことにより回避できますが、
前者だと何もしてなくてもCPUを食ってしまうし、後者だと重い処理を行っているときにUIの更新ができなくなってしまう
のでできれば別スレッドからBeginInvokeしたときにApplication.DoEventsを実行したいのですが…
- 97 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 16:04:51 ]
- とりあえず俺の環境では起きないんだが
- 98 名前：96 mailto:sage [2009/04/08(水) 17:32:32 ]
- >>97
こちらでは、スクロールバーの右の矢印部分を連打(結構なスピードで)すると簡単に発生するのですが…
スクロールバーの描画が破綻した後、右矢印部分になぜか点々(サイズ変更可能なウインドウに表示されてたり
するアレ)が表示されます。
こうなると、スクロールバーは完全に機能しなくなり、スクロールバーのあった部分は再描画が無効になります。
- 99 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 18:07:52 ]
- >>98
俺も結構な速度でやってみたんだけどな
それこそクリックしたら画面の女の子脱ぎますよと言われたくらいの速度でｗ
ほぼ同じ環境の後輩に同じことやらしてみたけど症状が出てない
一応環境
VISTA BUSINESS SP1(エアロ有効)
VS2008 Professional上でデバッグ実行
- 100 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 18:23:43 ]
- >>97のPCで問題を再現するには超人的なスピードでの連打が必要なんだよ、きっと。
>>98
こういうケースでは、スリープを追加するなどして
"連打" ではなく、一回のクリックで問題を再現させることを目指すと、原因がわかったりするよ。
例えば、DoEvents()の後にThread.Sleep(100);と書き、スクロールバーを右クリックしてみるといい。
運良くこっちと似た環境ならば、100％の確率でスタックオーバーフローするので
スタックトレースを見れば原因がわかるはず。
- 101 名前： [―{}@{}@{}-] デフォルトの名無しさん mailto:sage [2009/04/08(水) 18:25:08 ]
- >>98
ディスプレイドライバのせいだったりして
ハードウェアアクセラレータ無効にすると治るとかない？
- 102 名前：96 mailto:sage [2009/04/08(水) 18:44:52 ]
- >>99
こちらでは速めのダブルクリック程度の速度でも発生するのですが…
こちらの環境は
Geforce 9600GT 512MB
XP 32bit
VS2008 Pro
です。
>>100
スタックオーバーフローするのは、BeginInvoke内でdoEventがtrueになる前に何度もBegineInvokeが
実行されてしまうのが原因でした。これについては、Invokeの前にdoEventをtrueにすることにより解決できましたが、
スクロールバーが壊れるのとは別問題のようです。
>>101
ハードウェアアクセラレータは切ってみましたが、特に関係があるわけではないようです。
ドライバも最新のものにしてみましたが、改善しませんでした。
- 103 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 20:38:21 ]
- ほんとだうちの環境でも壊れたぞ。
- 104 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 21:12:13 ]
- >>102
うーん。自分の環境だと再現しないので勘になっちゃうけど。
DoEvents でもたぶん BeginInvoke なキューを処理する気がするから
このコードだと一度間に合わなくなればそれより優先度の低いメッセージは
まったく処理されなくなる希ガス
あとそもそも精度 100μs なんて無理って話は突っ込んでおいたほうが
いいのかな
- 105 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 21:35:32 ]
- >>96
環境によって差が出てるということは、
Control.BeginInvokeの発行間隔が処理時間より短いせいだと思う。
前の処理が終わらないうちに次のBeginInvokeが実行されないようにするか、
同期型のControl.Invokeにする。
あとはDoEventではなくpictureBox1.Updateを使うべきだろう。
- 106 名前：96 mailto:sage [2009/04/08(水) 22:10:18 ]
- >>104,105
それだと、タイマーのインターバルをゆっくりにすれば発生しないはずですが、それでも発生しますし、
インターバルが短くても、Application.DoEventsを取り除くと発生しなくなります。
また、フラグを立てて(バグってたけど)同時に何度もBeginInvokeされないようにはしているので、
>>102の通り、別問題な気がします。
>>104
>>100μsなんて無理
確かに精度はよくないのですが、実際に使うときには最短で200μs程度のインターバルで使用するので、
その間隔で使用する分には何とか使用できる程度の精度は出るようです。
>>105
このサンプルでは、画面の更新しかしていないためそれでもいいのですが、実際はボタン操作や
テキスト操作なども反映させるため、Application.DoEventsを使いたいのです。
- 107 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 22:29:01 ]
- DoEventsでやらずに、ピクチャーボックスのInvalidateメソッドを実行し、
描画はImageプロパティは使用せずに、Paintイベントで描画するようにすれば?
GraphicsオブジェクトはPaintイベントの引数eにe.Graphicsがあるからこれを使用して描画する
- 108 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 22:31:40 ]
- テキスト操作も更新するときはそいつのInvaridateを実行。
DoEvenｔsはプロセスすべてのイベントを処理するから重いんだよ。
- 109 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 23:03:36 ]
- μsはmsの間違いだと思う。
- 110 名前：デフォルトの名無しさん mailto:sage [2009/04/08(水) 23:34:43 ]
- 排他とかInvalidateでの再描画とかいくつか考慮は必要なのだが、
この方法でいけるはず。
基本はControl.InvokeもApplication.DoEventsも使わないことだな。
if (!abort)
{
//c.BeginInvoke(busyMethod);
Tick(this, EventArgs.Empty);
}
//pictureBox1.Image = image;
using (Graphics g = pictureBox1.CreateGraphics())
{
g.DrawImage(image, 0, 0);
}
Draw(count);
count++;
//Application.DoEvents();
- 111 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 00:08:41 ]
- >>96
なんか分かってるのか分かってないのかよく分からんコードだな、というのが率直な感想。
なぜそうしているのか理由や必然性がわからない部分が多すぎる。
ちょっとVB上がりのコピペプログラマの臭いがする。
つーか、せいぜい70hzでしか更新されない画面をusオーダーで更新して（そもそも不可能だけど）
なんか意味あるのかなw
- 112 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 01:04:43 ]
- >>110
テキストの更新をするだけならInvaridateで十分なのですが、ボタン操作やメニュー、ショートカットキー等々の
UIの操作を行った際に発生するイベントを処理するためにDoEventsを差し込んでいます。
そういう意味で、ボタン操作やテキストの更新と書きました。
>>111
VBの方はほとんど触ったこと無いですw
実際に使用する際には画面更新中に発生したTickの回数分だけ処理をとばすようにはするのですが、
その前にタイマーがちゃんと動作するかどうかを確認している際に発生したのがこの現象です。
サンプルの方はDock.Fillなはずのコントロールがリサイズできてしまうということを確認してもらうために
余計にコントロールを追加していたり、タイマーが回っているのを視覚的に確認するために画面更新していたり
しますが、実際にはウインドウにHScrollBarを貼り付けても発生しますし、TickのDrawを中身空っぽのforを
10万回回した後にDoEventsするだけでも発生します。
- 113 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 01:13:01 ]
- どんなに Interval の数値大きくしてもCPU使用率が上に張り付くんだけど
本当にこれで処理大丈夫なの？
- 114 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 01:29:36 ]
- >>112
あほな自家製タイマーがメッセージループを占有しなければ、
＞UIの操作を行った際に発生するイベント
はdoeventsなんか呼ばなくてもちゃんと処理されるのだけどね。
メッセージループ経由でのUIの更新は動画のような短時間での更新向きではない。
なんかWin3.1のころのメッセージループのアイドルにバックグランド処理をやらせる
のを念頭に置いたりしてないか。
- 115 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 02:46:55 ]
- マイクロ秒とかそもそもリアルタイムOSじゃないWindowsには過酷すぎる要求ではないか
- 116 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 09:13:24 ]
- >>112
ちょｗｗｗ
スレッド分けてる意味のないコードになってるってことじゃないのか…・
- 117 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 09:16:13 ]
- >>112
valid
Invalid
Invalidate
な
2回以上同じところを間違えると馬鹿みたいだぞ
- 118 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 09:50:34 ]
- 根本的にわかってないようだな
- 119 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 11:49:46 ]
- vb触った事無いらしいが
作りこみがVBにしかみえない
- 120 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 12:17:54 ]
- VBっぽい作り込みとC#っぽい作り込みって具体的に
どの辺が違うんですか？素で気になります。
初心者の書き方っぽいだけでVBが悪いわけじゃないのか
VBを使うと必然的にそうなるのかよく分からない。
もしかして.netのVBを指している訳じゃない？
- 121 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 13:26:42 ]
- VB6っぽいというべきだろうな。
.NETでDoEventsを使っているなら９割がた間違った使用法と考えるべき。
何のためのスレッドかぜんぜん理解していないようだし、
Control.BeginInvokeが何をしているかも理解してないな。
- 122 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 17:33:25 ]
- 誰かFormとマルチスレッドとConrol.BeginInvokeについて説明してやれよ
- 123 名前：96 mailto:sage [2009/04/09(木) 20:24:27 ]
- >>121
・Application.DoEventsは、処理中に発生したイベントをすべて処理する
・スレッドは重い処理などをバックグラウンドで処理させたり、処理を並列して行うことにより高速化を図る
・Control.Invokeは別スレッドからのUIの操作をUIを持つスレッドに行わせ、BeginInvokeは処理の完了を
待たずに制御を戻し、処理の状況を確認するためのIAsyncResultを返す
と理解しているのですが、違うのでしょうか?
もし違うのであれば、参考となるページでもいいので教えていただきたいのですが…
- 124 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 20:26:59 ]
- そこまでわかってれば、DoEventsを使う必要には迫られないはずだが
- 125 名前：デフォルトの名無しさん mailto:sage [2009/04/09(木) 23:46:32 ]
- >>123
VB6はバックグラウンド処理用にスレッドを自由に起動できなかった。
全部の処理はUIスレッドで実行するしかなかった。
だからビジーループ的な処理があると、それを実行している間はUIが
必然的に応答できなくなる。（だってその処理は、プロセス中の唯一のスレッドである
UIスレッドで実行しているのだから。）
その問題をやり過ごす（根本的解決ではない）ためにDoEventsは使われた。
ビジーループの中でDoEventsを実行してやると、その時点でキューにたまっていた
ウィンドウメッセージが全て処理される。つまりユーザー目線では、UIが操作に反応する。
自由にスレッドを起動できるドトネトではわざわざUIスレッドでビジーループを
書く必要がないから、わざわざApplication.DoEventsを使用する理由は普通ないはず。
- 126 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 00:05:44 ]
- >>123
バックグラウンドのスレは高速化じゃなく、ユーザへのレスをよくするのが目的では？
- 127 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 00:59:33 ]
- マルチコア（CPU）なら、マルチスレッドは高速化に寄与するよ。
- 128 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 01:48:03 ]
- もちろん、複数スレッドで同時に仕事をやらせればの話だけどね。
- 129 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 01:54:50 ]
- そもそも、高速化 = レスポンスとスループットの向上 と考えれば間違ってないでしょ
- 130 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 01:58:00 ]
- レスポンスとスループットはトレードオフになることが多いよ。
- 131 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 02:26:08 ]
- やりかたによるけど反応返ってこなくなるもんな。
- 132 名前：96 mailto:sage [2009/04/10(金) 02:37:10 ]
- >>125
では、今回のように別スレッドからBeginInvokeなどが連続して呼ばれて結果的にビジーループ
のようになってしまうような処理の場合、どのようにしてイベントを処理すればいいのでしょうか?
タイマーの精度をあきらめる(そもそも無茶らしいですが)として、
while (!abort)
{
while (doEvent && !abort)
{
Thread.Sleep(1);
}
...
Thread.Sleep(1);
}
としてもTickの内容が重たいとビジーループになってしまうのですが…
ここまでするくらいならSystem.Windows.Forms.Timerかなんかを使ってTickで処理時間分Intervalから引いていった方が
いいような気もしますがw
- 133 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 02:41:48 ]
- UIに限って言えば
UIが属していないスレッドがいくらビジーループになっても構わないのでは？
あと草が邪魔
- 134 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 09:00:49 ]
- よくわからんけど、多重呼び出しにならないよう待たせるか、
呼び出す度に重い処理のスレッド作るとか
- 135 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 09:23:03 ]
- どうせDOEVENTやってんだから普通にInvokeでやってみれば？
そんな重そうな処理でもなさそうだし
Invokeの中身を高速化するために、画像を先に作っといてInvokeで呼び出されている関数内で転送するだけにするとか
以上ド素人の意見でした。
- 136 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 10:29:34 ]
- そもそも96はどんなソフトを作ろうとしてんだ？
- 137 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 10:48:24 ]
- CodeDomProvider.CompileAssemblyFromSource()
でソースを動的にコンパイルした場合、そのソースの中から
アプリ本体のクラスを使うことはできるのでしょうか？
- 138 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 10:55:39 ]
- >>137
普通に出来るでしょ
参照アセンブリに追加すれば
コンパイルする前に参照するアセンブリをロードしなきゃいけないんだったかな
適当にそのアセンブリのクラスを使えばロードされる
- 139 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 10:59:48 ]
- >>137
CompilerParametersに参照をしたら出来るんじゃなかったっけ？
よく憶えてないけど
- 140 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 11:13:08 ]
- >>132
わざわざdoevents使うなんて
実質シングルスレッドで動かしてますよと公言するよーなもん
- 141 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 19:58:48 ]
- >>132
言ってることがよく分からないんだけど、
例えば仮に1msの処理時間が必要な処理があるとして、
この処理を同一のスレッドで1ms未満のインターバルで繰り返すことは
太陽を西から昇らせる以上に不可能だ、というのはOK？
失礼だがなんかこのあたりの当たり前のことを理解してない気もするんだが。
- 142 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 20:30:55 ]
- >>141
まずその処理が1msで終了するのか勘定してみるといい。
スレッド起動から勘定するんだぞ。
- 143 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 20:57:31 ]
- >>142?
- 144 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 21:09:47 ]
- >>142??
- 145 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 21:13:00 ]
- >>142???
- 146 名前：デフォルトの名無しさん mailto:sage [2009/04/10(金) 22:32:31 ]
- ＵＩスレッド以外からＵＩを操作すると壊れるってのも理解してないような気がする
- 147 名前：137 mailto:sage [2009/04/11(土) 01:44:04 ]
- >>138 >>139
CompilerParameters.ReferencedAssemblies.Add("EXEファイル名");
でできました。ありがとうございます。
- 148 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 04:43:38 ]
- ComboBoxコントロールなんですけど
ドロップダウンの表示幅を表示するテキストに合わせて伸縮させることは難しいでしょうか
- 149 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 08:12:32 ]
- オーナドローでググれば一撃
- 150 名前：96 mailto:sage [2009/04/11(土) 12:52:55 ]
- >>133
>>132で言ってるのは、別スレッドからTick終了後に間隔を開けずにまたTickが呼ばれるため、結果的に
UIを持つスレッドがビジーになってしまう、ということです。
>>141
そこについては理解しています。
上の方にも書きましたが、BeginInvokeが何度も呼ばれないようにフラグを立てています。
ですが、
Tick Tick
├───┤ ├───┤
├─────┤├─────┤├─────┤...
インターバル ↑ インターバル ↑ インターバル
↑:Tick呼び出し
となればTickとTickの間にほかのイベントを処理することが可能なのですが、今回の場合
Tick Tick
├─────────┤├─────────┤
├─────┤├─────┤├──┤├─────┤├──┤...
インターバル ↑ インターバル 待機 ↑ インターバル 待機
となってしまい、結果的にUIスレッドがビジーになってしまうため、ということを言いたかったのです。
わかりにくくてすいません。
>>146
BeginInvokeやInvokeでUIを持つスレッドに処理を任せても壊れてしまうのでしょうか?
別スレッドからUIを直接操作すると壊れる、ということは実験したことがあるのですが…
- 151 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 12:55:05 ]
- >>150
結果的にUIスレッドがビジーになってしまうため、 → ×
結果的にUIスレッドがビジーになってしまう → ○
です。
- 152 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 13:44:31 ]
- あんたはどんなアプリを作ろうとしてんだ
- 153 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 15:00:31 ]
- >>96=150=151
まず、設計が滅茶苦茶。原因は知識不足にあるのは明白なので、
勉強しろ(ここで問答しても埒が明かない)としか言えない
とりあえず、コードの不備だけ指摘すると、
UIスレッドでdoEvent=trueにしてるから、BeginInvokeが複数回呼ばれる可能性がある
タイミングによって、上記が全て完了する前にdoEvent=falseになっていることがある
その場合、更にBeginInvokeが複数回呼ばれる
で、暫くすると...＼(^o^)／
- 154 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 15:34:36 ]
- >>149
遅くなりましたけど、ありがとうございました。
オーナードローでいろいろ調べてやってみます。
- 155 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 15:44:18 ]
- doEventフラグがlockまたはvolatileで宣言されてない。
それにdoEventはBeginInvokeする前に設定しなきゃいかんだろ。
もっと言えばInvoke使えばフラグはいらない。
- 156 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 15:52:22 ]
- もひとつ、BeginInvokeでBitmapに描画、PictureBoxに設定、DoEventsの呼び出しを
やってるわけだが、Bitmapの描画はスレッド側、
つまりBeginInvoke呼び出し前に処理していいだろう。
何のためのスレッドだよ。BeginInvokeの中身は軽くしなきゃ。
- 157 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:00:08 ]
- >>153
> UIスレッドでdoEvent=trueにしてるから、BeginInvokeが複数回呼ばれる可能性がある
その点については、本人は治したと言ってるが、本当に治っているかどうか怪しいな
- 158 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:15:55 ]
- アニメーションを表示するのにpictureboxを使うものなのか？
直接スクリーンに描くにせよ、イメージにいったん描いて画面に転送するにせよ、
普通はPanelか何かにGraphices#drawImageを使うぞ。
そうすればControl.Invoke自体いらなくなる。
- 159 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:20:26 ]
- 普通はOnPaint、Invalidate、Updateを使うだろうな
ただし、バックグラウンドで生成した画像を表示する必要があるなら
PictureBoxを使ってもやってることは変わらないかも
- 160 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:25:47 ]
- >>159
動画のようなアニメーションにOnPaint、Invalidate、Updateはつかわんだろう。
はなはだ効率が悪いのに。
- 161 名前：96 mailto:sage [2009/04/11(土) 16:41:50 ]
- >>152
C#の勉強もかねて自分用の動画編集ソフトを作成しています。
>>153,155
その点については、>>100で指摘を受けてTick呼び出し前にdoEventをtrueにするように修正しましたが、
現在Invokeに置き換えて様子を見ています。
>>156
最終的な目標としては、もう一つスレッドを立ててそこでイメージを生成するようにしたいと考えています。
しかし、まだタイムラインのUIに手をつけたばかりなので、とりあえずTick内でイメージを生成するようにしていました。
>>157
上記の通り、Tickの前にdoEventをtrueにするようにし、BeginInvokeが重複して呼ばれることがないことを
確認しましたが、volatileをつけていなかったため、偶然だったのかもしれません。
>>158,159
PictureBoxよりもPanelに描画する方がいいのでしょうか?
OnPaintやControl.CreateGraphicsで直接描画するのとPictureBox.Imageにイメージをセットするのは
ほとんど変わらないものだと思っていたのですが…
- 162 名前：96 mailto:sage [2009/04/11(土) 16:48:26 ]
- これだとさっきと言いたいことが変わってる orz
>>156の部分の追記
ただ、ファイルアクセスがネックになってイメージの生成が遅れた場合に>>150の図のようになってしまうので、
これについてもどうにかしたいのですが…
- 163 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:50:27 ]
- アプリ見て大体想像していたが、動画編集アプリかよｗ
だったら、100マイクロ単位のタイマーなんてぜんぜん必要ねーじゃねーかよ。
なぁ、どっからマイクロ秒なんてものが必要と思ったんだ?
- 164 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 16:55:16 ]
- DirectShow使えばいいじゃん・・・
- 165 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 23:11:58 ]
- もうそこまでやるならDirectX使うべきだな
- 166 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 23:15:52 ]
- WinFormsでリアルタイムで動画イメージ生成して描画とかさすがにありえんわ
- 167 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 23:16:04 ]
- 勉強にケチつけないでいただきたい
- 168 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 23:23:40 ]
- >>167
偽物乙ｗ
>>165
DirectXにあまり期待してはならない。
しかも自分しか使わないソフトならいざ知らず、
ビデオカードによってはアレだ
- 169 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 23:37:22 ]
- 偽者とは違う
偽装するなら名前欄に番号でも入れるよ
- 170 名前：96 mailto:sage [2009/04/11(土) 23:38:53 ]
- >>163
30fpsで1フレーム辺り33.333...msで、再生していると徐々にずれてくるかなと思ったのですが、
どうにか100μs単位まで行かなくてもいけそうになりました。
ただ、どちらにしてもやり方的には変わらないので、根本的には解決できてないです。
>>164
DirectShowは、DirectShow.NETを触ったりしましたがさっぱりわかりませんでした。
いろんなDirectShow関連のサイトも行ってみましたが、全く歯が立ちませんでした orz
>>165
DirectXや3Dは全く触ったことがなく、調べてみるとほとんどC++みたいなのですが、
.NET上から触ることはできるのでしょうか?
- 171 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 23:44:32 ]
- >>170
managed directx
- 172 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 00:13:36 ]
- あのさ、編集ソフト内での再生ズレを考える必要ないの。（程度によるのは当然）
わかる？編集ソフト内での再生は映像と音声の同期さえあってれば適当な再生速度で十分なわけ。ミリ単位で十分なわけ。
そもそもあんたはマイクロ秒のズレなんてわかるんかよ。
ミリ秒単位でやったとしても1時間のもので40秒しかズレねーんだよ。
ファイルさえきっちり作成できればいいの。
後は、再生ソフトの役目なんだよ。
- 173 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 00:18:50 ]
- >>172
まあまあ。
それはそのソフト作る側の考え方によるだろ。
自分がそういうふうに作れって言われたわけじゃないんだからおちつけ。
- 174 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 00:22:16 ]
- これが落ち着かずにいられるかって！
- 175 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 01:11:12 ]
- >>170
そうか？
サンプル分かり易いと思うし、それにCodePlexにTimeLine.NETとかSplicerとかいった編集用のライブラリとかある。
- 176 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 01:17:58 ]
- >>172
納期が決まってるとか予算が決まってるならともかく
趣味レベルなら別にかまわんのじゃ？
編集ソフト内の再生ズレ、なくせるんだったらなくした方がいいと思うし。
- 177 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 08:15:18 ]
- C#の勉強もかねて・・・・
そういえばみんな言語始めるとき勉強はなにからやってるんだろう
俺は新しい言語をやる時に
画面のコントロールの簡単な使い方
標準的なファイルの入出力
簡単な入力チェック系
データベースの 接続・追加・更新・削除
位からやってる
あとはWEBかクライアントに合わせて色々やること増えるけど
- 178 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 08:33:54 ]
- またHello Worldからかよorz
- 179 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 10:15:50 ]
- 昔よくやってたのはラインアート作るとか。
今時だと、>>177 で出てるネタを押さえるようないいサンプルアプリが欲しいなぁ。
- 180 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 11:39:50 ]
- 俺の場合は、初めに電卓、次にタイマー等が用意されてるなら、
テトリスやリバーシみたいな簡単なゲームを作る事にしてる。
ある程度、実用 ( 娯楽 ) 性があるものを作成すると、理解が早い気がする。
- 181 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 12:35:22 ]
- たしかに作ってて多少モチベが上るようなのじゃないと
だれるもんね。
Web サービスのクライアントなんて
結構実装簡単だし、すぐ使えるからよさげじゃない？
REST API 公開してるサービスめちゃめちゃ多いし。
- 182 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 13:54:16 ]
- >>170
徐々にずれるのが嫌なら再生開始時からの経過時間を使って、
間隔を調整すればいいだろ。
- 183 名前：96 mailto:sage [2009/04/12(日) 14:26:29 ]
- >>172
>そもそもあんたはマイクロ秒のズレなんてわかるんかよ。
30fps時の端数分(333μs)ずつずれていくと、100フレームほどで1フレーム遅れる計算になります。
数秒再生して1フレームも遅れるのは結構致命的だと思うのですが…
>>175
C++やDirectX、COMを触ったことがないからだと思いますが、何が何だかさっぱり…
ISampleGrabberからIBaseFilterへとか、継承しているわけでもないのになぜキャストできるのでしょうか?
同じメソッドを実装するだけでキャストできるのかと思い、テスとしてみたのですが当然できるはずもなく。
Splicerはおもしろそうですね。
>>182
現在はTickが呼ばれるたびに誤差を計算して次に加算するように変更したので、多分μs単位で
いじらなくてもあまりずれないようにはなっていると思います。
- 184 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 17:54:19 ]
- >>161
＞OnPaintやControl.CreateGraphicsで直接描画するのとPictureBox.Imageにイメージをセットするのは
＞ほとんど変わらないものだと思っていたのですが…
Control.CreateGraphicsを使えば別のメソッドから使えるというのがメリットなのよ。
GUIはGUIスレッド以外から扱ったらいけないと思い込んでるようだけどこれは例外。
つまり、メッセージループを使ったりBeginInvokeを使ったりする必要がない。
メッセージループのことは気にせずに、
独自のスレッドで連続して処理問題ないということ。（普通はプライオリティを若干下げてやる。）
OnPaintやPictureBoxなどに処理を任せるのは画面が無効になったときの再描画の処理を
やってくれるからであって、短いサイクルで描画を繰り返す場合は、その必要性がない。
Control.CreateGraphicsを使えばInvalidateやUpdateを呼ばなくても指定したタイミングで描画することが出来る。
- 185 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 19:18:43 ]
- >>184
そんなトンデモ説を得意げに言っちゃだめw
最初の行の「別のメソッドから」は「別のスレッド」と言いたかったんだろうが、
そんな話見たことも聞いた事もない。
Control.CreateGraphicsを使う場合のメリットは、Invalidate⇒OnPaintという
通常の処理に比べてオーバーヘッドが少ないことなんじゃないの？
逆にデメリットは、描画処理を呼ぶトリガーをOnPaintに一本化できないことでしょ。
もっとも、>>96のように短い一定時間ごとに必ず描画するのならダーティー化
された場合のことを考えなくていいからデメリットと言えないんだろうけど。
- 186 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 19:30:05 ]
- 一応、Control.CreateGraphics はスレッドセーフだと言っておこう
- 187 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 19:36:55 ]
- >>186
すまん確かにそうだったw
グラフィック関連長いこと触ってないんで忘れてたよ。
- 188 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 20:13:37 ]
- >>96に最小限の修正を加えてろだに上げてみた。
kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/9025.txt
注、Stopのときの再描画処理としてpicturebox1にPaintイベントを追加している。
- 189 名前：デフォルトの名無しさん mailto:sage [2009/04/12(日) 20:55:18 ]
- 188です。lockの位置を間違ってた。
複数のスレッドからimageを使うことになるので、
lockはvoid Draw(int rad)全体にかけたほうがよかった。
だた、startフラグで制御してるのでただし実行に影響はないはず。
- 190 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 17:01:47 ]
- WinアプリでDataGridViewの行を大量に追加・削除するときって
SuspendLayoutとかの呼び出しをやった方がいいんだろうか？
位置を移動させるとかの場合は効きそうだけど今一歩やるべきかどうかの判断がつかないんだが・・・
今はおまじない的にやってるけども
- 191 名前：デフォルトの名無しさん mailto:sage [2009/04/13(月) 21:34:50 ]
- データソースをViewから切り離してから追加・削除すると速いかも
- 192 名前：デフォルトの名無しさん [2009/04/14(火) 20:34:17 ]
-
これ見てみｗ
国会の無駄な手当てでお手盛り人件費じゃぶじゃぶの実態ｗ
この経済危機に税金をなんでこういう公務員、国会職員に税金くれてるの？
↓
衆議院議員 渡辺周氏「呆れ返る国会のムダ呆れ返る国会のムダ」
www.choujintairiku.com/watanabes.html
内閣の閣議でどれだけお手盛り大盤振る舞い、浪費が行われているかわかるね。
これが自民党−麻生内閣の実態！！
- 193 名前：デフォルトの名無しさん mailto:sage [2009/04/14(火) 20:39:03 ]
- >>192
text/plainでくれ
- 194 名前：デフォルトの名無しさん mailto:sage [2009/04/14(火) 21:25:00 ]
- なんだかんだで結構親切に教えてくれるおまえらが好き。
|
 |
