PureBoard

genau darauf wollte ich mit meiner frage hinaus.
bei 400 bildern ist der verfügbare speicher eine 32bit systems nämlich praktisch voll, egal ob du 2MB RAM hast oder mehr.

also, mein tipp dazu wäre, dass du zuerst alle bilder durchgehst,
aus jedem ein Thumbnail erzeugst und das große wieder aus dem speicher löscht.
damit wärst du auf der sicheren seite, dass alle bilder,
die vorhanden sind und fehlerfrei geladen werden können,
auch einen thumbnail erhalten und in deiner liste erreichbar sind.

wenn der User dann eines der bilder anklickt zum groß anzeigen lassen,
kannst du immer noch mal das bild erneut laden.
ein einziges bild vom 3.8MB einzuladen ist praktisch "sofort auf knopfdruck"

du könntest dein proggi auch bei ersten start eine art "thumbs.db" erstellen lassen,
dass er bei nächsten start nur hinzugekommene bilder neu thumbnailen muss.

außerdem wäre es zu überlegen, ob du ein zusatztool schreibst,
das den screenshot-ordner automatisch durchgeht und alle BMPs in PNGs umwandelt.

> bei 400 bildern ist der verfügbare speicher eine 32bit systems nämlich praktisch voll, egal ob du 2MB RAM hast oder mehr
Ja, wenn ich alle meine Bilder lade, sind 518 MB Specher in Benutzung + dann nochmal die Thumbnails.

> also, mein tipp dazu wäre ...
Ja, ich glaube, das werde ich so machen. Eine Frage dazu: Bei ResizeImage() steht, dass das Handle des Images verändert wird. Daraus folgere ich, dass die ID gleich bleibt. Daraus schließe ich, dass ich nur 1 Bild im SPeicher habe, oder? Oder kopiert ResizeImage() das Bild und verkleinert das kopierte?

Weil ich momentan davon ausgehe, dass ResizeImage das bild nicht kopiert, um es zu verkleinern. Ansonsten verschwende ich gerade massig viel Speicher...
Ach ja: Und wenn ich ein 3,8 MB großes Bild verkleinere, nimmt es dann automatisch weniger Speicherplatz im RAM weg, der dann anderen Dingen/Programmen zur Verfügung steht? Doofe Frage, aber ich brauche gerade trotzdem ein "Ja" darauf, um mein Gewissen zu beruhigen.

> "thumbs.db"
Das wäre auch eine Überlegung. Allerdings käme wieder mehr Aufwand dazu, denn seit dem letzten Start könnten ja wieder Bilder hinzugekommen oder entfernt worden sein.
Diese Methode würde vielleicht das Laden beschleunigen, aber das ist IMHO nicht so dringend erforderlich.
Denn durch meine Technik, alles, was länger als einen Klick dauert, in einen Thread zu packen, kann der Benutzer sich noch in anderen Teilen des Programms durchklicken, während im Hintergrund die Bilder geladen werden.
Außerdem glaube ich nicht, dass jeder 139 Screenies hat, ich vermute mal, ich bin da eine Ausnahme. Nicht jeder weiß, dass F9 einen Screenshot macht
Und übrigens: Das Laden der vielen Bilder dauert bei mir auch nur 21 Sekunden auf meinem schnellen PC, die kann ja wohl jeder erübrigen.

> Eine Frage dazu: Bei ResizeImage() steht, dass das Handle des Images verändert wird. Daraus folgere ich, dass die ID gleich bleibt. Daraus schließe ich, dass ich nur 1 Bild im SPeicher habe, oder? Oder kopiert ResizeImage() das Bild und verkleinert das kopierte?

davon gehe ich mal aus, denn ich kann mir nicht vorstellen,
dass Fred einen Befehl so schlecht programmiert, dass ein riesen-speicherleck entsteht.

der hinweis mit dem geänderten Handle deutet für mich darauf hin,
dass OS-Intern ein neues Image in der neuen größe erzeugt wird,
die bilddaten resampled und übertragen, und das alte gelöscht.
PB-Intern bekommt das neue dann die alte ID.

im zweifelsfalle probier es halt mal aus, führe den vorgang mit 20 bildern aus,
und checke den speicherbedarf des prozesses im task-manager.

Getestet habe ich es nicht, aber mir ist auch noch aufgefallen, dass ein resized-es Image "doppelt" Speicher verbraucht.

Die Tatsache, dass die ID gleich gleibt, deutet für mich auch darauf hin, dass es nach wie vor nur ein Bild gibt.
Sollte ich was anderes feststellen, melde ich mich.