多数のオブジェクト (グラフ) (C++/Win32API) を表示するウィンドウで作業しています。これは GDI+ であり、ウィンドウ内でオブジェクトをドラッグするときのパフォーマンスを改善したいので、Direct2d でテスト コードを作成しました。私が見つけた（現在までの）最良のアプローチは次のとおりです（1000ノードと999エッジのグラフを使用）。
(基本的に、静的コンテンツをビットマップ バッファにバッファリングし、動いているものだけを描画します) ドラッグが開始されると (lbuttondown 状態など)、ドラッグされているノードと接続されたエッジを除く完全なグラフでベース レンダー ターゲットを作成し、GetBitmap を呼び出して、後で使用するために保存します。描画する必要がある場合 (mousemove イベントと lbuttondown 状態が true のため)、現在の hwndrendertarget をクリアし (背景ウォッシュ ホワイト)、移動中のノードに接続されているエッジを hwndrendertarget に描画し、保存ビットマップをhwndrendertarget に移動し、ノード ビットマップ (ノードが最初に DB に作成されたときに作成され、実際に描画して保存) を hwndrendertarget にコピーし、EndDraw を呼び出します。
これで問題なく動作します (ish)。気に入らないのは、ノードをすばやくドラッグすると、マウス カーソルがドラッグ中のノードの前に移動することです (距離は、ドラッグ/マウスムーブの速度に応じて、最悪の場合は約 1/ 2インチ）。私の参照アプリは MS Visio です。これで単一のオブジェクトをドラッグすると、ドラッグされているオブジェクト上の同じ位置にカーソルが留まっていることが示されます。おそらく +/- 1/2 ピクセルです。
私がまだ試していないのは、すべての（そして唯一の）描画操作を別のスレッドに移動することですが、これを試す前に、他のシングルスレッドアプローチがこの方法に勝る場合は、他の方法を調査したいと思います。
アップデート： 私はこれを改善してもう少し最適化しました。クラス全体のオブジェクトに移動し、他のブラシなどと同様にクラスの存続のために初期化した描画関数でエッジブラシを割り当ておよび割り当て解除していることに気付きました。カーソルは、すばやくドラッグされたときに、ドラッグされているオブジェクトから少し (2 ピクセル程度) はみ出すようになりました。オブジェクトは半径 15 ピクセルの円です。そのため、カーソルをドラッグすると、オブジェクトの中央 (カーソルがくっつくポイント) から最大 17 ピクセル離れた場所に移動できます。テストで興味深いことがわかりました。私のメイン モニターでは、カーソルがあるべきオブジェクトの中心点から 17 ピクセル以上、たとえば 25 ピクセルまで、ドラッグされるオブジェクトよりもカーソルが先に進む可能性があるという点で、ドラッグが悪化しています。修繕。拡張デスクトップの 2 番目のモニター (つまり、タスクバーなし) ドラッグは、前述の点で優れています。メイン モニターのタスクバーを非表示にし、そのモニターでアプリを実行してドラッグすると、パフォーマンスはセカンド モニターと同じになります。