オノデラの研究日記 in わんくま

おみごとー♪
お絵かきへたっぴなんで勉強になりますですー

派生してませんが、チラつきません。

http://cid-f11bb9fd8e1bc5f9.skydrive.live.com/self.aspx/Junktest/TestManyShapes.zip

おー。

今後の展開も知らず、さらに「ちらつき」うんぬんとは
関係ないところで、コメントしますが、、

今回のケースであれば、Panelを使わず、
MainFormに直接描画をかければ良いのでは？
と思いました。
# MainFormのOnPaintをoverrideして描画させます。
# ちらつき防止策は、Panelと同じく、base.SetStyle() 。

> えぴさん

　私もただの「丸」しか描いておりませんw

> ひどりさん

　なるほど～、確かにちらつきませんね。PictureBox 使えば Image プロパティを使ってしまうっていう手もあるんですね。

> ひらせさん

　私も Form に直接書いたほうが手軽だったんですが、掲示板のほうでは Panel を使っていたみたいなので、あえて Panel に描いてみました。Form だったら DoubleBuffer プロパティでもいけるのかな？

Form 直書きはスケーラビリティが低すぎます。

Form 内に、他にボタンなんかを配置する場合、クリッピングを自前でしなければなります。

そうしなければならない/そうした方がいい場合は、かなり少ないはずです。

描画先が Panel であっても、直描きはやはりスケーラビリティが低すぎます。

Paint イベントで描画処理を行うということは、ウィンドウの重なりの変化など、描画領域の大きさの変化が伴わない再描画でも、一連ののロジックが実行されることを意味します。

結果、描画処理が複雑であればあるほど、「単なる描き替え」時には「クリッピングによって実際には表示されるはずのない描画処理」のために CPU パワーが費やされることになります。

> 結果、描画処理が複雑であればあるほど、「単なる描き替え」時には「クリッピングによって実際には表示されるはずのない描画処理」のために CPU パワーが費やされることになります。

　うつ、確かにそうですね。掲示板に書かれていたコードに近い形で書こうとしていたので、そこまでは考えていませんでした。

　よくよく考えれば再描画する際に１枚のイメージをクリップ領域に１回だけ描画したほうがはるかにコストが少ないですね。

あぁ・・でも、
Bitmap転送する方法をとると、ウィンドウがリサイズしたときに重いですし、
ウィンドウサイズより大きなものを描画しようとすると、
相当なメモリを食うので注意が必要です。


描画系は、だいぶ「時と場合による」だと思います。

> ウィンドウがリサイズしたときに重いですし

　Windows Vista のウインドウのリサイズも同じような理由で重いですね。(リサイズごとに頂点バッファを毎回作成し直ているんだったっけ？)

＞Bitmap転送する方法をとると、ウィンドウがリサイズしたときに重いですし、

一般的にはウィンドウのリサイズよりもウィンドウの重なりの変化の方が頻繁に発生するはずなので、頻繁に発生する事象への対応を重視するべきなんじゃないかと。

で、この問題には、簡単にはリサイズイベントに毎回正直に応答しないことで対策可能です。

リサイズイベントでタイマを始動し、引き続きリサイズイベントが来るようならそのたびにタイマを再始動します。

最終的に、タイマイベントのハンドラでオフスクリーンの再構築と再描画を行います。

それで足りないようならもっと工夫することもできますが、ここでそれ以上頑張らなければならない状況はそうそうないはずです。

＞ウィンドウサイズより大きなものを描画しようとすると、

サンプルではオブジェクト１個ごとにオフスクリーンを持たせてますが、無くても十分成立します。

むしろその方がより一般解に近いものになりますね。

http://cid-f11bb9fd8e1bc5f9.skydrive.live.com/self.aspx/Junktest/TestManyShapes2.zip

＞描画系は、だいぶ「時と場合による」だと思います。

とは言っても、動画やゲーム、ＣＡＤなどの特定分野を除けばいくつかのパターンには集約されていく思います。

＞頂点バッファを毎回作成し直ている

リサイズされたウィンドウの分だけの再作成なので、そんなに遅いはずはないはずなんですけどねー

Vista READY じゃない、古いノートなんかで Vista を動かしていると如実に遅いですが。

ワクワクを思い出すんだ