VCL vs. FMX - Die Frage ist (vorerst) offiziell beantwortet

[stahli]

@Mavarik

Die Antwort auf die Fragestellung ist falsch - oder jedenfalls unzutreffend.

FMX hatte in der Beziehung erhebliche Probleme, auch in häufigeren Anwendungsfällen. Ich lese einfach mal heraus, dass man immer noch einigen Aufwand betreiben muss, um größere Datenmengen effektiv darzustellen (und eine Bearbeitung zu ermöglichen).

[Mavarik]

Zitat von stahli:

FMX hatte in der Beziehung erhebliche Probleme, auch in häufigeren Anwendungsfällen. Ich lese einfach mal heraus, dass man immer noch einigen Aufwand betreiben muss, um größere Datenmengen effektiv darzustellen (und eine Bearbeitung zu ermöglichen).

Also ich nutze keine ListBox für so viele Daten... Aber ich habe einen Testgemacht mit dem Grid.

Das Grid hat für die Daten ein eigenes ViewModel damit kann man schon sehr gut arbeiten. Und hat keinerlei visuelle Verzögerung.

um das ganze noch ThreadSave zu machen, habe ich mir fürs FDK einen Grid-View-Helper geschrieben, der im Thread beliebig viele Daten lesen und halten kann.
Hiermit halte ich z.B. für meine Buchhaltung - falls nötig - alle Kontobewegungen der letzten 15 Jahre. Wenn ich da durchs Konto blättere geht das so schnell wie es der Tastaturrepeat zulässt.

Mavarik

[stahli]

@Mavarik

Das klingt gut. So etwas meine ich.

Aber dafür hast Du ja offenbar extra einen Handler gebaut.

Out of the Box funktioniert es also offenbar nicht.


Zu meinen FMX-Zeiten bestand dann noch das Problem, dass ständige Neuzeichnungsorgien ausgelöst wurden. Das scheint ja dann wohl nicht mehr so zu sein.


@jbg

Ah ja, ok.
Das kommt mir noch in etwa bekannt vor...

[Mavarik]

Zitat von stahli:

Aber dafür hast Du ja offenbar extra einen Handler gebaut.

Out of the Box funktioniert es also offenbar nicht.

Zu meinen FMX-Zeiten bestand dann noch das Problem, dass ständige Neuzeichnungsorgien ausgelöst wurden. Das scheint ja dann wohl nicht mehr so zu sein.

Mein Handler ist "nur" dafür da, ob meinen Thread vom Viewmodel zu entkoppeln... Es geht auch mit Bordmitteln..

Für die Updates: BeginUpdate / EndUpdate... Das gibt es auch für den kompletten Screen. Da zeichnet dann so lange nix, bis Du endupdate sagst und schwupp ist dein UI da. Mit einem VRAM-Screen-Update.

[jbg]

Zitat von stahli:

Scrollt denn inzwischen eine Listbox mit 100.000 Einträgen flüssig

Scrollen ja. Man muss die Items aber erstmal reinbekommen.

Zitat:

Wie lange braucht das Binden/Befüllen einer solchen Listbox?

Für 100000 Strings brauchte meine PC (3.6GHz 100 Sekunden)

Das Ablöschen der Items (Clear) dauerte doppelt so lange.



Mit was ist die ListBox beschäftigt:

1. Performance-Bremse Nummer Eins sind die TComponent.Notification Aufrufe. Jedes bereits hinzugefügte Item muss natürlich über das Hinzufügen/Entfernen eines Siblings informiert werden, egal ob es damit was anfängt oder nicht. Das ist der Nachteil den man hat, wenn man auch Strings als TComponent behandelt.

2. Die Items.Add Methode liefert den Index des hinzugefügten Strings zurück. Da man sich aber entschieden hat, dass die internen DoAdd... Methoden diesen nicht rausrücken und man bei einem Add bei einer unsortierten List nicht auf die Idee kam, einfach "Count-1" zurückzugeben, wird am Schluss indirekt ein IndexOf gemacht, der dank Generic TList<TFmxObject> "ewig" braucht je mehr Elemente in der Liste sind.