BackgroundWorkerでRunWorkerCompletedが発生しない (ID:147388)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文

# 以下、求める回答になっているかどうかは分かりませんが。

> resizeイベントが発生するからこそ必要になってくるんですね。
その「調整」に長い時間(数ミリ秒以上)を要するのであれば、
そもそもの作り方を変える必要があるかもしれません。

Resize イベントというものは、ドラッグ座標の変化に応じて
何回も続けて呼び出されるものですから、個々の処理時間が長い場合、
リサイズ操作や再描画が阻害されてしまうことになります。

そして、「リサイズ処理」や「スクロール時の描画処理」が重い場合は、
単にスレッドを分けただけでは問題を解決できないことが少なくありません。
これは、座標計算等はワーカースレッドでも行えるものの、最終的な
画面描画処理は、結局 UI スレッドが担当するしかないためです。

改修案としては、たとえばリサイズ中には描画処理を中止してしまい、
リサイズ完了後に描画しなおすことで、リサイズのパフォーマンスを
向上させるといった方法があります。

もしもリサイズ中にも画面を表示させたい場合には、リサイズ中は
内容を簡素化させたり計算精度を低下させることで高速に描画できるようにし、
リサイズ完了後に正確な内容で再描画することで対応するといった手が使われます。

たとえばリアルタイム表示のグラフなどの場合は、リサイズ中はデータを蓄えるようにし、
リサイズ完了後に、溜めておいたデータをまとめて描画するといった手法をとります。

以下、参考資料として

DOBON.NET プログラミング道「フォームのリサイズが終了するまでコントロールの大きさを変えない」
http://dobon.net/vb/dotnet/form/preventcontrolresize.html

TechEd 2004 「T5-407」
http://www.masatohirai.com/GeniusSite/Showsrus

ステップ 7 ハンズオン シリーズ「Windows フォームにおけるパフォーマンスの向上」
http://www.microsoft.com/japan/seminar/msdn/step7/performanceup/control/play.aspx
http://www.microsoft.com/japan/seminar/msdn/step7/performanceup/asynchronous/play.aspx

←解決時は質問者本人がここをチェックしてください。

戻る