3

私は現在、(Juce フレームワークを使用して) C++ で作成されたいくつかのオーディオ アプリケーションの GUI の設計と開発を行っています。

これまでのところ、「フィルム ストリップ」スタイルの画像を使用してコンポーネントをアニメーション化することにより、ビットマップ グラフィックスを使用してカスタム スライダーとダイヤルを作成してきました (つまり、ユーザーがスライダーを操作すると、フィルムのオフセットを変更するメソッドがトリガーされます)。 -コンポーネントの外観を変更するためのストリップ イメージ)。元の画像のサイズと「フレーム」の数に応じて、CPU 使用率は劇的に変化します。

まず、CPU 消費の観点から使用するのに最も効率的なビットマップ ファイル形式は何ですか? 現時点では、PNG 画像を使用しています。

次に、これらの種類のグラフィック コンポーネントにベクター グラフィックスを使用する方が効率的でしょうか? ビットマップ グラフィックスとベクター グラフィックスの主な違いは理解していますが、GUI の操作に関する CPU 使用率に関する情報は見つかりませんでした。

または、CPU 使用率は、使用されている特定のメソッド/関数/ライブラリ/フレームワークに依存しますか?

ありがとう！

4

4 に答える 4

2

それとも、使用されている特定のメソッド/関数/ライブラリ/フレームワークによって CPU 消費が低下するのでしょうか?

これらのいずれかがそれに影響を与える可能性があります。

ピクセルベースのイメージは、サイズが大きいほどディスクから読み取るのに時間がかかる場合があります。圧縮されたタイプは、解凍に時間がかかる場合があります。ベクトルが読み込まれると、レンダリングに時間がかかる場合があります。

そうは言っても、画像タイプの選択がそのパフォーマンスに影響を与えるとは絶対に思いません. コード例を提供しなかったため、それ以上の推測は困難です。

一般に、イメージの実行時コストは、イメージがロードされるときに発生すると予想されます。したがって、画像オブジェクトを作成するときはいつでも。いたるところに画像を作成すると、おそらく費用がかかります。フィルム ストリップは、画像を一度読み込んでキャッシュするのではなく、画像を再作成している可能性があります。

于 2011-09-02T18:25:17.047 に答える
0

ビットマップ グラフィックスとベクター グラフィックスを選択する前に、グラフィック プロセッサがベクター グラフィックスまたはビットマップ グラフィックスをサポートしているかどうかを調べてください。ベクトルとして描画するのに時間がかかるものもあります。

ダブルバッファリングを試しましたか？
これは、ディスプレイ (グラフィックス プロセッサ) が別のバッファをロードしている間に、メモリ内のバッファに書き込む場所です。

リソースからビットマップを一度ロードします。それらをメモリ スナップショットとして保存して、形式から変換する追加コストを回避します。

お使いのグラフィック プロセッサは「ブリッティング」をサポートしていますか? ブリッティングとは、グラフィック プロセッサがメモリ (ビットマップ) 内の四角形の領域をコピーし、表示する前にオプションの操作 (既存のビットとの XOR など) を適用して表示できる場所です。

概要: レンダリング速度を向上させるには、ファイルの画像をビットマップ形式に一度だけ変換してください。これをどこかに保管してください。必要に応じて、この変換されたビットマップを参照してください。次に、ダブル バッファリングを調査して実装します。最後に、ビットブリッティングまたはブリッティングを調査して使用します。

ここでも、設計の見直し、要件の削除、ループの展開、ポインターを介した画像の受け渡しとコピーの比較、ブール論理とカルノー (sp?) マップを使用した "if" ステートメントの削減など、他の最適化ルールが適用されます。

于 2011-09-02T18:25:24.710 に答える
0

一般に、ベクター グラフィックスをレンダリングするための計算は、ビットマップの四角形の領域を画面にブリットするよりも時間がかかります。ただし、基本的な UI については、どちらも特に集中する必要はありません。

おそらくプロファイリングを行う必要があります。必要以上に頻繁に再描画している可能性があります。または、PNG から描画しようとするたびに PNG がデコードされている可能性があります。（私はジュースに精通していません。）

単純な Windows アプリの場合、起動時にベクター グラフィックスをデバイス依存のビットマップにレンダリングし、ビットマップから画面にブリットするだけです。ベクターを使用すると、DPI に依存しなくなります。デバイス依存のビットマップからのブリッティングは、ピクセルのブロックを描画する最も速い方法です。デバイス依存のビットマップにレンダリングするときにカラー マッチングが行われるため、画面描画に ICM のオーバーヘッドも発生しないと思います。

于 2011-09-02T19:37:20.033 に答える
-1

ベクターグラフィックスはずっと前に捨てられました-ビットマップグラフィックスはより高性能です。重要なのは、ビットマップをGPUに一度送信してから、単純なコピーでさらに永久にレンダリングできるということです。

次に、GPUは独自のテクスチャ圧縮を使用します。DirectXはDXT5だと思いますが、GPUがテクスチャを見るとき、何からロードしたかは関係ありません。

ただし、最新のCPUは、GPUが統合されていても、単純なGUIレンダリングではまったく問題がないはずです。苦労している場合は、使用しているテクニックをもう一度見てみましょう。おそらく、フレームワークが遅いか、フレームワークの使用が最適ではありません。

于 2011-09-02T19:46:29.773 に答える