1

オブジェクトのデバッグとトレースで答えを得ることが非常に難しいところまで来てしまったので、助けが必要です。

私がやろうとしていること: 私のスクリーン キャプチャ ペット プロジェクトの履歴フォーム。履歴には、すべての画像をサムネイルとして一覧表示する必要があります (例: picasa)。

私がやったこと: HistoryItem:UserControl を作成しました。この履歴項目には、いくつかのボタン、チェック ボックス、ラベル、画像ボックスがあります。ボタンは、画像の削除/編集/コピー用です。チェック ボックスは 1 つまたは複数の画像を選択するために使用され、ラベルは情報テキスト用です。画像ボックスは、パスであるパブリック プロパティから画像を取得し、メソッドは、コントロールが読み込まれたときにそれを表示する比例サムネイルを作成します。このユーザー コントロールには、2 つのパブリック イベントがあります。1 つはイメージを削除するためのもので、もう 1 つはすべてのコントロールを通過するマウスの入力とマウスから離れるためのイベントをバブリングするためのものです。これにはEventBroadcastProviderを使用します。コントロールの上にマウスを移動すると、ボタンが表示されるので、バブリングは便利です。dispose メソッドが拡張され、手動でイベントを削除しました。

すべての画像のパスを含む xml ファイルをループすることによって、すべての画像が読み込まれます。この XML の各画像に対して、フロー レイアウト パネルに追加される新しい HioryItem を作成します (並べ替えを行い、読み込まれる画像の量を制限するためのコーディングを少し行った後)。

問題: 履歴フォームを起動し、フロー レイアウト パネルに HistoryItem カスタム コントロールを追加すると、メモリ使用量が大幅に増加します。履歴フォームを閉じて、処分できるものは何でも処分し、GC.Collect() を呼び出そうとしても、メモリの増加は残ります。画像やイベントのように適切に破棄できなかったオブジェクトを検索しますが、それらを使用した場所はどこでも破棄されます。問題は、複数の原因によるものと思われます。1 つはバブリングのイベントが適切に破棄されていないことであり、もう 1 つは画像ボックス自体からのものです。これはすべて、画像処理やイベントさえも行わずにカスタム コントロールのみが読み込まれるときに、すべてのコードを限定バージョンにコメントすることで確認できました。イベントがなければ、メモリ消費量は公理的に 20% 削減されます。


したがって、私の本当の質問は、このロジック、フロー レイアウト パネル、およびピクチャ ボックスを使用したカスタム コントロールが、大量の画像をサムネイルとして表示するための最適なソリューションであるかどうかです。

ありがとうございました!

4

1 に答える 1

1

私はかつてこれを正確に行ったことがありますが、メモリ管理に関してはひどいものです。たとえば、GDI ハンドルの数が増えるリスクがあり (たとえば、すべてのコントロールが Font または他の GDI オブジェクト インスタンスを作成する場合)、この問題は GC.Collect() では解決できません。

私は ComponentOwl.com で働いており、Better Thumbnail Browserと呼ばれる画像サムネイルを管理するためのコントロールを開発しました。これは、サムネイルの読み込み、サイズ変更、キャッシュも行うことができます。

より良いサムネイル ブラウザの概要

Better ListView Expressと呼ばれる無料のコンポーネントもあり、画像のサムネイルを引き続きサポートしています。

于 2012-12-01T20:29:23.410 に答える