アプリケーションの起動時に、アイコンのキャッシュ (24x24 32bbp 事前に乗算された argb ビットマップ) を構築します。このキャッシュには、およそ 1,000 個のアイテムが含まれています。メモリとパフォーマンスの両方の理由から、このキャッシュに同じ画像を複数回保存したくありません。最適な方法は、各ビットマップがキャッシュに入るときに何らかの crc を作成し、新しいビットマップをこの crcs のリストと比較することであると考えました。
メモリにのみロードされるビットマップからcrcを作成する良い(そして速い)方法は何ですか?
または、私は完全に間違った方向に進んでいますか?ビットマップキャッシュを構築するためのより良い方法はありますか?
ハンスが言ったことを繰り返しますが、これはできると思いますが、CRC は使用するには不適切なアルゴリズムです。
代わりに、生成されたビットマップのバイトの MD5 ハッシュを作成できます。私の計算では、画像のサイズは 2Kb 以上である必要があります。ハッシュを生成するには、ビットマップ全体で計算するか、n番目のバイトごとにこっそりと計算することができます。ハッシュ側では高速ですが、それらを抽出する必要があるため、メモリ使用量が増える可能性があります。バイトを新しい配列に入れます。
n バイトごとにスキップする場合は、4 または 2 を使用します。4 を使用すると、連続する各ピクセルから 1 つのコンポーネントを読み取ることを意味し、2 を使用すると、連続する各ピクセルから 2 つのコンポーネントを読み取ることを意味します。
ただし、MD5 は非常に高速であり、ビットマップ全体をハッシュするだけで高速になることがわかります (単体テストでこれをベンチマークします)。
唯一のことは、ハッシュであることを事前に知らずに特定のビットマップを生成する必要があるかどうかを事前に確認する方法がわかりません。ハッシュであることを知る唯一の方法は、それを生成することです。その場合、その時点までに、新しい画像を保存することもできます。画像キャッシュ配列内の余分な要素がユニバースを壊すことはありません。
スペースと起動時間を実際に節約するためにここで本当に必要なことは、イメージを生成する前に、それが別のイメージと同じになるかどうかを知ることです。これらの画像が動的に生成されることを考えると、2 つの同一の画像が生成される場合、それらは同じパラメーターを使用した同じメソッド呼び出しによって生成されるのでしょうか?
その場合は、代わりに、生成された各画像に、画像を生成するメソッドの 1 つ以上のハッシュコード ( を使用object.GetHashCode())でタグ付けすることを検討できます ( をMethodInfo呼び出すことで、メソッド自体の内部で取得できますMethodBase.GetCurrentMethod()。渡されます。メソッドのハッシュコードは、ランタイムのメソッド ハンドル (メソッドごとに一意) を使用するため、非常に信頼性があります。そこで発生する可能性がある唯一のハッシュ コード圧縮は、ハンドルが 64 ビットの 64 ビット マシン上ですが、ハッシュ コードは 32 です。ただし、実際には、2 つの別々のメソッド ハンドルの最初の 32 ビットを同じにするためにアプリケーションに膨大な量のコードが必要になるため、このような衝突はめったに発生しません。
もちろん、個々のパラメーターのハッシュ コードは、それらのパラメーターの型に適切なハッシュ コード機能がない限り、信頼性がはるかに低くなります。
この解決策は決して完璧ではありません (最悪の場合でも重複が発生する可能性があります) が、速度は上がると思います。ただし、私が言うように、それは常に同じ呼び出しによって生成される複製された画像に依存しています。
CRC には、ハッシュ関数と同じ欠陥があります。CRC の値が同じであっても、画像が同一であることは証明されません。あなたのプログラムはランダムに、しかしまれに間違った画像を表示します。
何か他のものが必要です。ビットマップを取得したファイル名と同様です。