Firemonkey Grid Performance

[CHackbart]

Hi,

ja ich weiß das Thema ist alt und hat soo einen Bart Derzeit sitze ich daran ein Projekt für Mac, Android und iOS fertigzustellen und beiße mir ein bisschen die Zähne daran aus. Die Hauptanwendung läuft ausnahmslos mit einer eigenen Engine via OpenGL und kann selbst HEVC UHD Streams flüssig darstellen (allerdings nicht auf Mobilgeräten). Jedoch nutze ich in der Einstellungsseite normales Firemonkey.
Für die Kanalverwaltung habe ich mich entschieden ein TGrid zu benutzen, da TListview beim Erstellen der Liste untragbar langsam ist. 5000 Einträge dauern schnell mal 1.5 Sekunden und TGrid kann man immerhin via GetValue relativ schnell befüllen. Leider ist letzteres extrem unperformant, vor allem beim Scrollen durch große Listen.
Bei DVB-S kommt man zum Beispiel auf mehrere tausend Sender und gelangt schnell an die Grenzen der Unbedienbarkeit. Putzig eigentlich, da ich im eigenen OSD damit keinerlei Probleme habe und die CPU Last nicht einmal messbar ist. TMS habe ich testweise auch probiert, aber die sind noch langsamer. Kennt jemand eine einfache Alternative die nicht für jede Zelle ein eigenes Objekt erstellt?

Christian
PS: Das Verwenden einer nativen Anzeige wollte ich eigentlich vermeiden.

[mkinzler]

http://www.fmxexpress.com/blazing-fa...droid-and-ios/

[Sherlock]

Kurz gesagt ist es wohl leider so: FMX verhält sich zu nativen Komponenten wie vor Jahren Pascal zu Assembler.

Etwas länger: Wenn es auf Performance in Anwendungen ankommt, die über die Kindergartenbeispiele von Embarcadero hinausgehen, kommt man an nativen Komponenten nicht vorbei.

Sherlock

[CHackbart]

Hmm 300 Dollar wollte ich dafür eigentlich nicht ausgeben, aber ich teste die Demo mal ob das wirklich *blazing fast* ist.

@Sherlock: Das hab ich schon befürchtet, was aber das ganze System adabsurdum führt. Zum Glück beschränkt sich in meinem Fall die notwendige Darstellung nur auf ein Formular und das holt sich die Daten über ein festes Interface aus einer von der Darstellung getrennten Klasse.

[Sir Rufo]

Das Erzeugen von 5000 Einträgen in der ListView dauert auf einem Mobile-Device schon so seine 1,5 Sekunden.

Der Trick besteht aber darin, die Einträge bei einem Refresh wiederzuverwenden und dann sind 5000 Einträge in ca. 120ms abgefrühstückt. Ich kann dmit leben.

[Harry Stahl]

Leider hast Du nicht erwähnt, mit welcher Delphi-Version Du arbeitest. Denn ab XE6 ist die Performance des Grids ERHEBLICH gesteigert worden. Unter Windows ist es annähernd so schnell wie das VCL-Grid.

Erst unter XE6/XE7 habe ich mein PC-Rechnungsprogramm auch für die MAC-Plattform fertig gemacht, weil erst ab da die Geschwindigkeit mit mehreren 1000 Einträgen im Grid OK ist.

[CHackbart]

Die Anwendung ist in XE5 erstellt.

Christian

[Mavarik]

Grids habe ich ganz von meiner Liste gestrichen... Listbox auch.. ListView geht... ist mir aber zu "unhandlich" während der Designtime.
Für alles andere erzeuge ich mir eine Scrollbox und darauf Images mit meinen Inhalten...

Das scrollt dann so schnell das man es nicht glauben kann...

Außerdem muss man ja nicht 5000 oder mehr Einträge sofort erzeugen. Wie viele können dargestellt werden? 5?
Also erzeuge ich mir die ersten 100... Bis einer dahin gescrollt hat hab ich wieder 100 erzeugt. usw.

Mavarik

[Harry Stahl]

OK, bei XE5 kannst Du es leider vergessen. Das hakelt und ist leider wenig performant. Aber ab XE6 ist das wirklich ziemlich schnell.

Zitat von Mavarik:

Außerdem muss man ja nicht 5000 oder mehr Einträge sofort erzeugen. Wie viele können dargestellt werden? 5?
Mavarik

Das macht das Grid ja auch nicht. Mit GetValue werden nur die erzeugt, die gerade angezeigt werden müssen. Die Daten selber würde ich natürlich nie im Grid selber verwalten. Es ist nach meinem Verständnis immer nur ein Anzeige- oder Auswahlobjekt.

[CHackbart]

Ich habe XE7 in der Demo getestet und das geht messbar schneller. Da ich deswegen nicht gleich eine neue Delphi Version kaufen wollte habe ich eine eigene "Grid"-Komponente geschrieben. Das Ergebnis ist besser als ich gehofft habe