2

古い C++Builder / Delphi アプリケーションの外観を最新化しようとしているときに、ビジュアル テーマ（ビジュアル スタイル）を有効にしましたが、追加されたパフォーマンス ヒット テーマの量に驚きました。たとえば、主要なセットアップ ページ (11 タブ、200 コントロールのモンスター ダイアログ。開発時間と再トレーニング コストの理由から、今はやり直したくありません):

  • テーマを有効にしない場合:フォームとそのコントロールの構築に約 0.1 秒(QueryPerformanceCounter で測定)、メニュー項目をクリックしてからフォームが表示されるまでに約 0.9 秒(ストップウォッチで測定)。エンドユーザーにはあまり目立ちません。
  • テーマが有効な場合:フォームとそのコントロールを構築するのに約 0.6 秒、メニュー項目をクリックしてからフォームが表示されるまで約 1.5 秒。エンドユーザーにとって非常に目立ちます。

Windows XP デスクトップと Windows 7 VM の両方で同様の結果が得られます。

この特定のケースを改善するために実行できる手順 (ダイアログのタブを遅延読み込みするか、完全に再設計するなど) があることは認識していますが、テーマがそのような顕著なパフォーマンス ヒットを追加するのは一般的ですか? このパフォーマンスへの影響を回避するための簡単な提案はありますか?

4

2 に答える 2

3

わお。1 つのフォームに 200 個のコントロールがあったかどうかはわかりません。ここにいくつかの提案があります。

  • これは、必要に応じてダイアログを作成するのではなく、アプリケーションの起動時に一度ダイアログを作成し、必要に応じて表示する特殊なケースです。

  • また、コンストラクターまたは OnShow イベントで何が起こっているかを調べます。BeginUpdate/EndUpdate が有利になるリストを作成していますか?

  • OnResize イベントなどで、フォームが作成されてから 1 回実行されるまで待機できる複数回発生するコードはありますか?

  • どのような種類のコントロールを使用していますか? あるタイプのコントロールのペイントが特に遅い場合は、より速くペイントするコントロールに置き換えることができる場合があります。ただし、これにはいくつかのテストが必要です。

于 2009-12-04T22:48:02.897 に答える
1

コントロールでダブルバッファリングをオンにしてみると、ほぼ同じ動作が得られ、このアプローチによって多少高速化されましたが、アプリケーションテーマのサポートを採用する前にパフォーマンスに近づくことはありませんでした。

于 2009-12-08T21:17:50.283 に答える