1

ドラッグ＆ドロップでテーブルをデザインできるコンポーネントを作成しています。

ドラッグ＆ドロップ部分とテーブルレンダリング部分はなんとか書けたのですが、問題があります。

私はダブル バッファリングを使用してちらつきを減らし、メモリ内のビットマップに描画し、その一部を画面に bitblt します。

手順:

  1. テーブルをメモリ内ビットマップに描画します (これは非常に大きくなる可能性があり、最大値まで)。
  2. コントロール キャンバス上の部分的なインメモリ ビットマップ コンテンツ。

問題は、メモリ内のビットマップが大きくなるほど、bitblt 操作が (明らかに) 遅くなることです。

私の質問は：

  • これのパフォーマンスを改善するにはどうすればよいですか？代替ソリューションにも興味があります。

コード：

procedure TCustomGraphicScrollControl.Paint;
var 
    x,y: Integer;
begin
  inherited;

  // Rendering is done in the child class. FRender is a 4-bit color depth 
  // in-memory bitmap. 

  if HorzScrollBar.Visible then x := HorzScrollBar.Position else x:=0;
  if VertScrollBar.Visible then y := VertScrollBar.Position else y:=0;

  // We will create a second in-memory bitmap, with the same dimensions as the control
  // and the same color depth as FRender. This way BitBlt will be a little faster, as it won't be needed to do any conversion.

  // bitblt part of the large in-memory bitmap to screen
  BitBlt(
    FCanvas.Handle,
    0,
    0,
    Width,
    Height,
    FRender.Canvas.Handle,
    x,
    y,
    SRCCOPY
  );
end;

アップデート：

コードと質問から「トリプル バッファリング」と UpdateScrollBars を削除しました。

4

1 に答える 1

2
  1. テーブルをメモリ内ビットマップに描画します (これは非常に大きくなる可能性があり、最大値まで)。
  2. コントロール キャンバス上の部分的なインメモリ ビットマップ コンテンツをブリットします。

問題は、メモリ内のビットマップが大きくなるほど、bitblt 操作が (明らかに) 遅くなることです。

問題を正しく診断したとは思えません。ブリットのパフォーマンスは、主にターゲットの四角形のサイズによって決まります。非常に大きなソース ビットマップの場合、メモリ アクセスの効率が低下する可能性があることは事実です。ただし、ソース ビットマップが十分に大きくなり、ブリットによって読み取られる各スキャンラインが異なるキャッシュ ラインに存在するようになると、パフォーマンスはターゲットの四角形のサイズで一定になるはずです。

したがって、このことから得られる明らかな結論は、メモリ内ビットマップのサイズが大きくなるにつれてパフォーマンスが低下する場合、そのメモリ内ビットマップの描画がボトルネックであるということです。その詳細が含まれていないため、詳細な最適化の提案を提供できません。しかし、次のステップは、パフォーマンスのボトルネックが実際にどこにあるのかを突き止めることです。私が信じているように、ボトルネックが完全なメモリ内ビットマップである場合は、そこでパフォーマンスを改善する方法を見つける必要があります。

于 2014-06-18T11:54:58.560 に答える