私はC＃でゲームに取り組んでいます（2.0または3.5のどちらかはまだ決定されていません）。ゲームは六角形のグリッドを持つマップ上でプレイされます。このマップのUIはダブルバッファリングを使用する必要があることを感謝します（多くのレイヤーがあるため、描画が遅くなります）。スタイルを介してダブルバッファリングを有効にすることも、独自のバッファを作成して自分で処理することもできることを知っています。私がウェブ上で見つけたほとんどの推奨事項は、それを自分で処理することです。なぜだろう？明らかに、これにより、制御ダブルバッファリングに固有の仮定を回避できますが、それらの仮定が何であるかはわかりません。
繰り返しになりますが、コントロールをダブルバッファリングする方法を説明するコードを探しているのではなく、ダブルバッファリングスタイルを使用してCLR / Controlクラスに処理させるのではなく、なぜ自分でビルドするのでしょうか。
MSから：
アニメーションなどのグラフィックを多用するアプリケーションの場合、BufferedGraphicsManagerによって提供されるBufferedGraphicsContextの代わりに専用のBufferedGraphicsContextを使用することで、パフォーマンスを向上させることができる場合があります。これにより、アプリケーションに関連する他のすべてのバッファリングされたグラフィックスを管理するパフォーマンスオーバーヘッドを発生させることなく、グラフィックスバッファを個別に作成および管理できますが、アプリケーションによって消費されるメモリは大きくなります。
編集：私はまた、役立つかもしれないボブパウエルからのこの記事を見つけました：
手動のダブルバッファリングは、システムが必要ない場合に役立つことがあるため、背景が不透明か透明か、またはより複雑なバッファリングシステムを作成する場合など、想定を立ててください。手動のダブルバッファリングを正しく行うために従う必要のある簡単なルールがいくつかあります。
まず、描画サイクルごとに新しいバックバッファを作成しないでください。ウィンドウのクライアントサイズが変更された場合にのみ、ビットマップを作成または破棄します。次に、必要なサイズのビットマップのみを作成します。ピクセルのクリアには時間がかかるため、必要以上のピクセルがある場合は、プロセッササイクルを無駄にしているだけです。最後に、最も簡単な描画方法を使用して、ビットマップを画面にコピーします。DrawImageUnscaledはここに行く方法です。
編集：別の理由は、コントロール自体ではなく、アプリケーションにバッファリングを制御させたい場合があることです。
WFAでは、ダブルバッファリングは、カスタムグラフィックス領域のちらつきを完全に排除せずにパフォーマンスを低下させます。ImageButtonsとLabelsで構築されたゲームを作成する場合のように、組み込みのGUI要素の場合、組み込みのダブルバッファーモードは、コントロールツリーの再描画を非表示にするのに最適です。ただし、カスタム描画領域に使用する場合、いくつかの大きな問題があります。
基本的なウィンドウGUIを単一バッファーに保ちながら、バッファーを制御する領域を作成することにより、これらの問題の両方が最小限に抑えられます。
ダブルバッファリングメソッドは、バックバッファとしてビットマップオブジェクトを作成し、準備ができたら描画領域に描画するか、カスタム描画領域のバッファリングを管理するために個別のBufferedGraphicsContextを設定するのと同じくらい簡単です。