Große Anzahl Bilder laden

[OneTwo]

Hallo Leute.

Ich möchte Bilder in eine JList-Laden. Es soll lediglich eine Preview der Bilder angezeigt werden, also ein kleines Thumbnail. Es können durchaus auch größere Mengen Bilder in die Liste geladen werden. Derzeit versuche ich sie über BufferedImage mit getScaledImage zu laden. Leider ist das sehr speicherhungrig, so dass die Anwendung irgendwann mit einem heap overflow baden geht. Bereits bei rund 200 Bildern ist der Speicher voll. Die Heapsize zu erhöhen ist für mich keine Lösung.

Meine Frage: Gibt es einen performanten Weg Bilder als Thumbnails in einer Liste darzustellen? Evtl. eine andere Komponente als die JList?

Wie gesagt, es sollen nur Thumbnails, anhand derer die eigentlichen Bilder ausgewählt werden können, angezeigt werden.

Vielen Dank schon mal und Gruß

 

[Wildcard]

Du kannst dir relativ leicht ausrechnen wie viel Speicher du pro Bild brauchst. Es hängt davon ab welches ColorModel verwendet wird und wie groß die Pixel Fläche ist.
Kommst du zu dem Schluß das du mehr Bilder brauchst als du im Speicher halten kannst/willst, kommst du rein physikalisch nicht um Caching herum.

 

[OneTwo]

Danke für die schnelle Antwort.

An solchen Lösungen bin ich ja im Prinzip interessiert. Mit dem physikalischen Speicher werde ich nicht hinkommen. Was genau meinst Du denn mit Caching? Nur die Bilder laden, die zum Betrachtungszeitpunkt angezeigt werden?

Ich habe leider schon länger vergebens nach Beispielen dafür gesucht. Gibt es ein Best-Practice für solche Probleme?

 

[Wildcard]

Eine einfach Lösung kann zB so aussehen:
Schreib einen Renderer für die JList oder was auch immer du nehmen willst. Der Renderer besorgt sich die Bilder dann aus einem Cache. Merkt der Cache das er das angefragte Bild nicht vorrätig hat, lädt er es nach und gibt es zurück.
Der Cache muss nun entscheiden wann er ein Bild wieder aus dem Speicher wirft. Eine einfache, aber nicht besonders clevere Strategie wäre zB die Bilder in SoftReferences zu speichern. Die VM gibt sie dann frei sobald mehr Speicher benötigt wird als vorhanden ist. Der Nachteil ist, das du keine Kontrolle darüber hast welche Bilder entfernt werden und welche nicht.
Wenn du aufgrund deines Use-Case bestimmte Annahmen treffen kannst welche Bilder vermutlich nicht mehr benötigt werden, dann kannst du auch deine eigene Caching Strategie entwickeln. Etwas aufwendiger, aber wahrscheinlich performanter.

 

[newcron]

Du kommst auch mit deutlich mehr Bildern im speicher hin, wenn du es nur richtig anstellst. Ich Spiele derzeit mit 1000 Bildern (im speicher und gleichzeitig auf dem Bildschirm) herum, und habe keine Performanceprobleme auf einem Steinzeit-PC.

Was ich mache: ich lade die Bilder einzeln, erstelle von ihnen ein Thumbnail und schmeiße die originale weg. Dazu habe ich noch eine Wrapperklasse, die ein Bild abstrahiert, mit der ich das Originalbild bei bedarf nachladen kann. Die entsprechende methode hat noch einen booleschen Parameter, der festlegt, ob das originalbild gecached werden soll (sie also eine referenz auf dieses bild behält) oder nicht.

Funktioniert prima!

 

[Wildcard]

Wie gesagt: es ist eine einfache Rechnung:
Wieviel Speicher x steht zur Verfügung
Wieviel Bilder y können maximal benötigt werden
Wieviel Speicher z braucht jedes einzelne Bild (Größe mal bytes pro Pixel)

Wenn y*z>x dann braucht man eine Caching Strategie, ansonsten nicht.

habe keine Performanceprobleme auf einem Steinzeit-PC.

Das ist auch keine Performance Frage, sondern ein Frage ob der Heap ausreicht.

 

[OneTwo]

Schreib einen Renderer für die JList oder was auch immer du nehmen willst. Der Renderer besorgt sich die Bilder dann aus einem Cache.

Der Renderer muss bei der Lösung jedoch dafür Sorge tragen, dass er nur die Bilder vom Cache abfragt, die auch gerade angezeigt werden sollen. Ansonsten wäre das Problem des Ladens *aller* Bilder ja nur von der eigentlichen Anwendung in die Cache-Anwendung verschoben. Wenn ich Dich richtig verstehe, meinst Du mit Cache einen Thread/ein seperate Anwedung, quasi einen Proxy?

Was ich mache: ich lade die Bilder einzeln, erstelle von ihnen ein Thumbnail und schmeiße die originale weg.

Wie genau stellst Du das denn an? Im Prinzip wollte ich es auch so machen.
- Bild mittels ImageIO in ein BufferedImage laden
- BufferedImage via getScaledImage verkleinern (Thumbnail-Größe)
- Thumbnail der JList hinzufügen => nächstes Bild.

Klar ist, dass er so natürlich jedes Bild erstmal vollständig in den Speicher lädt. Da werde ich ja auch nicht drumrum kommen, wenn ich on-the-fly die Thumbnails erstellen will. Aber wie bereits geschrieben ist da bereits bei weniger als 200 Bildern schluss. Eigentlich sollte sich der GC doch darum kümmern die nicht mehr referenzierten Bilder aus dem Speicher zu entfernen.

Generell vielleicht noch mal kurz die Problemstellung etwas näher erläutert:
Der Nutzer des Programms soll einen beliebigen Ordner auf der Platte wählen können und die Bilder dann in der GUI als Thumbnails dargestellt bekommen. Im Prinzip eine einfache Thumbnail-Ansicht wie im Windows Explorer etc. Hieraus kann er sich bestimmte Bilder aussuchen für die weitere Arbeit mit diesen. Die Thumbnails muss ich also on-the-fly erstellen.

 

[Wildcard]

Der Renderer muss bei der Lösung jedoch dafür Sorge tragen, dass er nur die Bilder vom Cache abfragt, die auch gerade angezeigt werden sollen. Ansonsten wäre das Problem des Ladens *aller* Bilder ja nur von der eigentlichen Anwendung in die Cache-Anwendung verschoben. Wenn ich Dich richtig verstehe, meinst Du mit Cache einen Thread/ein seperate Anwedung, quasi einen Proxy?

Der Code der JList ruft den Renderer nur auf den sichtbaren Elementen auf (sollte er zumindest).

Aber wie bereits geschrieben ist da bereits bei weniger als 200 Bildern schluss. Eigentlich sollte sich der GC doch darum kümmern die nicht mehr referenzierten Bilder aus dem Speicher zu entfernen.

Rechne doch erstmal nach ob das bei bei dir auch hinkommt. Wenn nicht, dann können die Originale nicht aus dem Speicher gelöscht werden, weil du sie noch irgendwie referenzierst. Die VisualVM und ein Heap-Dump können dir dabei helfen.

Generell vielleicht noch mal kurz die Problemstellung etwas näher erläutert:
Der Nutzer des Programms soll einen beliebigen Ordner auf der Platte wählen können und die Bilder dann in der GUI als Thumbnails dargestellt bekommen. Im Prinzip eine einfache Thumbnail-Ansicht wie im Windows Explorer etc. Hieraus kann er sich bestimmte Bilder aussuchen für die weitere Arbeit mit diesen. Die Thumbnails muss ich also on-the-fly erstellen.

Nun, alle mir bekannten 'Explorer' berechnen Thumbnails zwar on-the-fly und bei Bedarf, persistieren die Thumbnails dann aber. Bei win32 ist das eine thumbs.db pro Verzeichnis, bei GTK zb ein .thumbnail im Home Verzeichnis.