私は実際にこれを解決しましたが、後世のために投稿しています。
デュアル モニター システムの DataGridView で非常に奇妙な問題が発生しました。この問題は、コントロールの再描画が非常に遅い (完全な再描画の場合は 30 秒など) として現れますが、画面の 1 つにある場合のみです。一方、再描画速度は問題ありません。
最新の非ベータ ドライバー (175 など) を搭載した Nvidia 8800 GT を使用しています。ドライバーのバグですか?私はこの特定の構成で生活しなければならないので、それは空中に置いておきます。(ただし、ATI カードでは発生しません...)
描画速度はセルの内容とは関係がなく、カスタム描画を行ってもパフォーマンスはまったく向上しません。塗りつぶされた四角形を描画する場合でも同様です。
後で、ElementHost (System.Windows.Forms.Integration 名前空間から) をフォームに配置すると問題が解決することがわかりました。いじる必要はありません。DataGridView もオンになっているフォームの子である必要があります。Visibleプロパティが true である限り、サイズを (0, 0) に変更できます。
アプリケーションに .NET 3/3.5 依存関係を明示的に追加したくありません。リフレクションを使用して、(可能であれば) 実行時にこのコントロールを作成するメソッドを作成します。それは機能し、少なくとも、必要なライブラリを持たないマシンでは正常に失敗します-単に遅くなるだけです.
このメソッドを使用すると、アプリの実行中に修正を適用することもできるため、(Spy++ を使用して) フォームで WPF ライブラリがどのように変更されているかを簡単に確認できます。
試行錯誤を繰り返した結果、(フォームだけではなく) コントロール自体でダブル バッファリングを有効にすると、問題が解決することがわかりました。
そのため、DoubleBuffering を有効にできるように、DataGridView に基づいてカスタム クラスを作成するだけで済みます。それでおしまい!
class CustomDataGridView: DataGridView
{
public CustomDataGridView()
{
DoubleBuffered = true;
}
}
グリッドのすべてのインスタンスがこのカスタム バージョンを使用している限り、すべて問題ありません。これが原因でサブクラス ソリューションを使用できない状況に遭遇した場合 (コードがない場合)、そのコントロールをフォームに挿入しようとすることができると思います :) (リフレクションを使用して DoubleBuffered プロパティを外部から強制的にオンにして、依存関係をもう一度回避しようとする可能性が高くなります)。
そんな些細なことで、こんなにも多くの時間を奪われてしまうのは悲しいことです...