Listview mit Firemonkey

[Rollo62]

Wenn man wirklich 2500+ Bitmaps laden will dann sollte man die vielleicht nicht alle im Speicher halten.
Mit dem Ansatz von Harry könnte man ein Fenster in den Daten laden, und die Bitmaps entsprechend nachladen.

Weil ich mit diversen LowMemory Applikation Events zu kämpfen hatte (habe) frage ich mich ständig:
Wie speichere ich am Besten meine Bilder (Thumbnails) auf den Mobile Devices ?

- Nachladen von File ist nicht so besonders performat
- Gespeichert in Sqlite Datenbank, aber legt Sqlite das doch wieder voll im Speicher an ?
- Irgendeine andere Datenbank-Lösung, statt Sqlite ?
FdMemoryTable liegt wohl auch komplett im Speicher, oder nicht ?
- Benutzen eines OnCalculateFields Events, um die Bitmaps dynamisch zu generieren ?
- Speichern in einer eigens dafür erstellten Klasse ?

Die perfekte Antwort dafür suche ich noch, es scheint alles Vor- und Nachteile zu haben.

Rollo

[Sherlock]

Kleine Zwischenfrage zu Deinen Gedanken, Rollo: Warum glaubst Du, daß Bilder aus Dateien zu laden weniger Performant sein soll als sie aus einer SQLite DB zu ziehen? Du weisst, daß SQLite dateibasiert ist? Nur mal so als Denkanstoß

Sherlock

[Rollo62]

Hallo Sherlok,

ja, richtig.

Ich glaube aber einfach das Datenbanken solche Prozesse super-optimiert haben (Wunschdenken).
Es geht ja um kleinere Thumbnails, größere Bilder würde ich auch immer über Linik nachladen.

Aber wenn man auf MobileDevices eine ListView mit kleinen Vorschaubildern machen möchte wäre doch
eine einfache Datenbank dafür elegant.

Jedenfalls ist mir noch nicht klar was hier generell der Beste Weg ist.

Rollo

[Peter666]

ich steh gerade ein bisschen auf dem Schlauch, aber gibt es eine Möglichkeit diverse TListViewItems zu verstecken? Sowas wie eine Visible Eigenschaft, als listview.items[1].visible := false ist ja nicht implementiert.

[Sherlock]

Zitat von Peter666:

ich steh gerade ein bisschen auf dem Schlauch, aber gibt es eine Möglichkeit diverse TListViewItems zu verstecken? Sowas wie eine Visible Eigenschaft, als listview.items[1].visible := false ist ja nicht implementiert.

Außer neu aufbauen, und die betreffenden Items nicht mitzuerzeugen ist mir nichts bekannt. Sorry... FMX ist gegenüber VCL leider in sehr vielen Dingen noch furchtbar weit zurück. Mir fällt da als abschreckendes Beispiel noch das TDateEdit ein...Grauslig.

Sherlock

[Peter666]

Zitat von Sherlock:

Außer neu aufbauen, und die betreffenden Items nicht mitzuerzeugen ist mir nichts bekannt. Sorry... FMX ist gegenüber VCL leider in sehr vielen Dingen noch furchtbar weit zurück. Mir fällt da als abschreckendes Beispiel noch das TDateEdit ein...Grauslig.

Sherlock

Das ist doch Mist Ich hab gesehen das die Filterfunktion da sowas macht, aber da muss man wohl mehr als nur ein bisschen hand anlegen, wenn man das mit einem eigenen Filter machen will. Schade eigentlich, weil TListview ist bockenlahm. Das fängt schon mit sowas an:

Delphi-Quellcode:

for LItem in FNewItems do
      LItem.CreateObjects;

Hat jemand mal zum Spaß 5000 Einträge oder mehr in eine TListView geschrieben? Das geht recht schnell, aber nach dem Endupdate wird jede Einzelne TListViewItem initialisiert und TAppearanceListView.ResetViewAppearance aufgerufen. Dort erfolgt ein LItemObjects.ResetObjects(AItem, GetFinalItemSize); und zwar von allen Einträgen. Das ganze wäre wesentlich performanter, wenn das nur die sichtbaren Objekte beträfe. So dauert es 3 Sekunden auf einem Android und da kommt dann gerne ein Anwendung reagiert nicht mehr vom System.

[Darlo]

Hab gerade kein Delphi hier, aber haben ListviewItems einen Parent? Wenn ja kann man ja dadrüber die Sichtbarkeit steuern. Alternativ Height := 0.

[bra]

Zitat von Sherlock:

Kleine Zwischenfrage zu Deinen Gedanken, Rollo: Warum glaubst Du, daß Bilder aus Dateien zu laden weniger Performant sein soll als sie aus einer SQLite DB zu ziehen? Du weisst, daß SQLite dateibasiert ist? Nur mal so als Denkanstoß

Auf mobilen Systemen rate ich davon ab, Bilder oder Binärdaten in einer SQLite-DB zu speichern. Das ist dort nämlich krötenlangsam.
Steht auch irgendwo in der Doku von SQLite, dass ab einer bestimmten Datengröße die Performance unterirdisch ist.
https://www.sqlite.org/intern-v-extern-blob.html