Hallo, könnt ihr mir Tipps geben, wie ich am besten viele kleine Bild-Dateien speichern kann? Ich entwickele das ganze in C#. Zur Zeit bin ich bei etwa 2.000 JPEG-Bilder mit je etwa 20-30kB. Diese müsste ich alle so schnell wie möglich in den RAM bringen. Ich denke mal 2.000 Bilder "einfach" in einen Ordner zu schmeißen, dürfte nicht die beste Möglichkeit sein. Doch wie löse ich das sonst? Klar, ich kann Unterordner anlegen, aber trotzdem muss ich ja immernoch 2.000 Datei-Streams öffnen, lesen und schließen, was sicherlich nicht sehr schnell sein dürfte. Also, evtl. könnt ihr mir da ja weiter helfen. Würde es evtl. z.B. mit einer SQLite-Datenbank besser geh'n, wenn ich die dafür "missbrauchen" würde? Freu mich schon auf euere Vorschläge. MfG Julian
Kein direkter Lösungsvorschlag, aber schau doch mal wie Amarok (http://amarok.kde.org) das macht. Ich würde die Files vermutlich beim ersten mal "cachen", also eine Art mmap aufbauen (ein File von ~30MB größe wo alle Bilder drin sind, und dazu einen Index mit den Dateinamen und position innerhalt des cachefiles. Dazu hash).
alle in eine Datei und als memory mapped file in den Speicher einblenden. Das wäre zumindest in C das schnellstmögliche, ob das in C# geht weiß ich nicht.
PS: Torsten meint das ja auch. Hatte ich nicht gelesen, sorry.
> Würde es evtl. z.B. mit einer SQLite-Datenbank besser geh'n, Wir wissen zwar nicht wozu das alles sinnvoll sein soll, weil du natürlich zu faul warst über das Problem was zu schrieben, aber wir nehmen mal an es geht um etwas wie einen MP3 Player, und wundern uns zwar wieso mehr als ein Cover, nämlich das des aktuell gespielten Songs, im RAM sein sollte, aber auch das scheint irgendeinen dummen Grund zu haben über den du uns natürlich nichts geschrieben hast. Am schnellsten liest du 50MB ein, in dem du eine einzige Datei sequentiell liest, weil dann der Sektorzugriff per FAT etc. optimal gecacht und ge-pre-fetcht werden kann. Das ist sogar etwas schneller als wenn du nur den Speicherbereich auf die Datei mappst, vorausgesetzt du musst wirklich jetzt auf die Daten zugreifen, denn das Mapping produziert page faults die alle einzeln bearbeitet werden müssen. Wie viel langsamer es aber ist als ein Verzeichnis von 2000 Dateien sequentiell zu durchforsten und jede Datei einzeln zu lesen, hängt auch vom Speichermedium ab. Ja, es ist langsamer, aber vermutlich erträglich. Zumindest wäre so was einfacher zu verwalten wenn Bilder hinzukommen oder entfernt werden. Wenn du nur EIN Bild (eben das zum aktuellen Song) aus den 2000 laden willst, ist immer noch ein Verzeichnis absolut tauglich, aber du könntest z.B. nach Anfangsbuchstaben in 26 Unterverzeichnisse gehen und nach dem zweiten Buchstaben in eine weitere Stufe damit du quasi einen Index für den Zugriff auf EINE Datei hast ohne alle 1999 Dateinamen in einem Verzeichnis sinnlos zu durchsuchen.
Hallo, ja, das ganze ist für einen "MP3-Player", jedoch der etwas besonderen Art, ist mehr ein "Just for Fun - Cooler Look"-Projekt. Ich brauche daher alle Cover's im RAM, da ich zum einem Cover-Flow über zwei 22°-Monster betreibe (und da die Cover's je nach Benutzer recht schnell "durchrasen" und es nicht ruckel'n soll, müssen die halt alle schon bereit stehen) und zum anderen erstelle ich eine Liste aller Alben, halt mit den Cover's, und wenn man bei 2x 22° scrollt, brauch ich die Cover's ebenfalls verdammt schnell, damit es nicht ruckelt. Keine Angst, es gibt "für den Benutzer" natürlich eine kleinere Ansicht, die Monster-Ansicht nutzt eigentlich nur der Computer, wenn er zum nächsten Album springt, sieht halt cool aus ;) Also im großen und Ganzen brauche ich eigentlich immer alle Cover's direkt abrufbereit, daher wollte ich die gleich beim Programmstart in dem RAM laden. Hab das ganze jetzt mal mit der "alles in einen Ordner"-Methode probiert und in einer SQLite-DB einen Index angelegt. Das ganze geht doch schneller wie gedacht, also es ist eigentlich noch verschmerzbar, auch wenn es wohl mit euren Tipps schneller geh'n würde. Aber gut, ist nur der Programmstart^^ Von daher lass ich es jetzt erst mal so und werde später mal die von euch erwähnten Methoden anschauen, und auch mal etwas Amarok "untersuchen". Auf jeden Fall schon mal Danke für eure Hilfe :) Viele Grüße Julian
Julian W. schrieb: > ch brauche daher alle Cover's im RAM, da ich zum einem Cover-Flow über > zwei 22°-Monster betreibe vermutlich meinst du 22". wie aber denkst du, dass ein 15kB Albumcover auf einem 22 Zöller aussieht? Tip: fängt mit sch an und hört mit eiße auf Was spricht denn dagegen am Programmstart die Bilder im Hintergrund zu laden? andererseits: .Net hat doch da bestimmt auch eine Lösung um Programressourcen in einer Datei zu verwalten und zu laden. vorteil von so was ist, dass die Zuigriffsmechanismen schon vom Framework bereitgestellt werden. Füg halt neue Cover, immer mit in die Datei.
MaWin schrieb: > Wenn du nur EIN Bild (eben das zum aktuellen Song) aus den 2000 laden > willst, ist immer noch ein Verzeichnis absolut tauglich, aber du > könntest z.B. nach Anfangsbuchstaben in 26 Unterverzeichnisse gehen und > nach dem zweiten Buchstaben in eine weitere Stufe damit du quasi einen > Index für den Zugriff auf EINE Datei hast ohne alle 1999 Dateinamen in > einem Verzeichnis sinnlos zu durchsuchen. Bei aktuellen Dateisystemen (NTFS nehme ich an, wenn C#) ist das nicht nötig, da die Verzeichniseinträge sowieso in einem B+-Baum o.ä. verwaltet werden.
Vlad Tepesch schrieb: > vermutlich meinst du 22". > wie aber denkst du, dass ein 15kB Albumcover auf einem 22 Zöller > aussieht? > Tip: fängt mit sch an und hört mit eiße auf Wer sagt denn, dass ich das 200x200 große Cover auf 1680x1050 ziehe ;) Aber einige Cover's (nicht viele, etwa 50 Stück, meine Lieblings-Alben eben) hab ich auch in hochauflösender Form vorliegen, die Stelle ich dann in Vollbild dar und dass sieht ganz brauchbar aus. Aber was denkst du, wie viele Cover's auf 1680x2100 passen, und stell dir vor, da scrollst du noch mit richtig Tempo durch. Also da muss ich schnell Bilder nachliefern können, sonst ruckelts. Coda schrieb: > Was für eine API benutzt du denn? OpenGL? Als API zum zeichnen benutze ich DirectX, zur Sound-Wiedergabe BASS. Aber fragt mich nichts zu DirectX, das ist alles im Grunde nur "geklauter Code", aus etlichen Tutorials, so wirklich durchblicken tu ich den noch nicht und aus "Urheberrechtlich" Sicht wahrscheinlich auch nicht für eine Veröffentlichung brauchbar. Außerdem funzt der Code nur auf meinem PC, auf meinem Laptob will's einfach nicht laufen, keine Ahnung, warum. Aber das ganze DirectX "Gekritzel" setzt auf die API eines "MediaCenter" auf, dass ich selbst entwickle, und als Freeware, evtl. auch openSource, veröffentlichen werde. Also keine Angst, dass ganze ist nicht nur Just for Fun, nur wenn man Monatelang mit der Programmierung zubringt und das ganze so nach "0815"-Standard-Player aussieht und man nicht weiß, was für besondere Mechanismen im Hintergrund arbeiten, hat man irgendwann das Verlangen, seinem Programm doch einen besonderen "Touch" zu geben. Daher diese bunte Cover Geschichte. Falls ihr euch fragt, was das besondere an dem Programm ist, dann kann ich euch hier weiterhelfen. Das Programm läuft nämlich nur als "Client", daher Cache ich auch die Cover's lokal, da diese aus dem Internet kommen. Das ganze MediaCenter läuft nämlich als Server-Client-Architektur. Dabei gibt es einen "zentralen" Server, eine MySQL-DB. Diese enthält alle Songs, Alben, Interpreten, Filme, Geners, usw., die im System vorhanden sind. Die Medien-Dateien selbst sind per http erreichbar und können auf ganz unterschiedlichen Servern liegen, so liegen z.B. alle Filme bei mir auf einem http-Server im lokalen Netz, die komplette Musik auf einem vServer. Als http-Server setzt ich lighttpd ein, aber mit mod_secodownload, ansonsten könnte ja jeder die Dateien abrufen, was ja nicht im Sinne des Erfinders ist^^ Alle Lieder werden also aus dem Internet geladen, dabei wird natürlich clever gecachet, ist z.B. der aktuelle Song fertig gecacht, so wird als der in der Playlist nächste und übernächste Song jeweils 10s gecacht. Ist das getan und es steht immer noch Bandbreite zum Download zur Verfügung, cacht er wiederum das nächste Lied und immer so weiter, bis die 100MB (oder wie viel man dem Programm halt gewährt) Cache, der im RAM liegt, voll sind. Des weiteren hab ich noch einen kleinen http-Server in das MediaCenter integriert, der eine für das iPod/iPhone optimierte Seite ausgibt, womit man die Wiedergabe "primitiv" steuern kann. So was ähnliches wie iTunes DJ halt, nur momentan kann man die Playlist noch nicht bearbeiten. Steht aber auf der ToDo-List. Und zu guter Letzt sollt das Projekt noch meine via RS232 angebundenen RGB-Led's passenden zur Musik ansteuern, wobei das noch in den Kinderschuhen steckt, wird wohl eher auf sowas wie 'ne Lichterorgel hinauslaufen, da BMP-Erkennung nicht wirklich funktioniert und ich ohne brauchabren BMP nicht weiß, wie ich einen Algorithmus entwickeln soll, der die LED's bunt blicken lässt :/. So, viel Text, deswegen hier mal ein Screenshot, ist aber nicht ganz aktuell: http://data.projects-tutorials.de/screenshot.jpg Viele Grüße Julian
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.