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

[Mavarik]

Zitat von Codehunter:

Über Window-Handles. Deswegen geht das bei FMX auch nicht.

Siehe Daniels Post - geht doch - wieder ein Gegenargument weg!

Zitat von Mavarik:

Das mag ja alles so sein, nur wenn du des gar nicht brauchst bei einem DB-Frontend, dafür aber mit FMX mehr Mannstunden investierst, dann hast du am Ende nichts erreicht.

Wieso mehr Mannstunden? Die Entwicklung ist nahezu die gleiche wie unter VCL. Die visuelle Darstellung ist schneller und ich bin sofort cross Plattform. Ich nenne das Win-Win.

Zitat von Bambini:

Bei komplexere UI's kippt das recht schnell, sofern man überhaupt die passenden UI Controls für FMX findet.

Passende UI-Controls sind eine Frage des persönlichen Geschmackes...
Aber FMX funktioniert wie eine Game-Engine... Stelle die Daten schnell genug bereit und Du bekommst 60 oder mehr Frames/s.

Das bedeutet, dein UI baut sich genau so schnell auf, wie es dein TFT darstellen kann. Schneller geht es nicht. (Es sei den Du hast einen Monitor mir einer höheren Framerate).

Meine Version vom Pacman macht problemlos 1500 Frames/s.

Mavarik

[stahli]

Scrollt denn inzwischen eine Listbox mit 100.000 Einträgen flüssig (mal unabhängig von der Sinnhaftigkeit ungefilterter großer Datenmengen)?

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

Wenn es schnell und flüssig geht, welcher Aufwand muss dafür inzwischen betrieben werden.

(Mit XE3 war das quasi nicht machbar.)

[himitsu]

Zitat von Daniel:

Accessibility geht bei FireMonkey, siehe
http://docwiki.embarcadero.com/RADSt...hilfen-Package

Im Prinzip wird da im Hintergund eine Ersatzstruktur aufgebaut ... quasi 'ne Kopie der Daten, auf die Programme zugreifen können.
Diese unsichtbare Struktur muß informell mit der Sichbaren übereinstimmen
UND die zugreifenden Programme müssen diese Hintergrundinfos auch verwenden.

Hab ja nie behauptet es ginge nicht
* man muß es nur erstmal explizit nachrüsten
* die Accessibility-Architektur bildet natürlich selten die koplette GUI 1:1 ab (Fremdkomponenten?)
* und hat Emba auch alle Funktionen MSAA implementiert?

[Fritzew]

Also Crossplattform ist es in meinen Augen nicht. Was da fehlt ist opengl unter Windows.

der 3d part benötigt auch noch einiges um wirklich benutzbar zu sein.
Ich arbeite seit 20 Jahren im CAD Bereich und wenn ich mir das ansehe was FMX da im 3d bietet........

[bra]

Zitat von Mavarik:

Selbstverständlich - FMX ist mit der entsprechenden Grafikkarte um ein vielfaches schneller. Schöner sowieso und die Gestaltungsmöglichkeiten sind viel größer!

Und wieviele hier programmieren Spiele oder Grafikprogramme die als Zielgruppe Anwender mit der "entsprechenden Grafikkarte" haben? Ich lehne mich mal weit aus dem Fenster und behaupt für den Großteil sind eher Businesskunden die Zielgruppe und da sind Grafikkarten wohl so ziemlich das Letzte, was in einem PC eine Priorität hat.

[Mavarik]

Zitat von stahli:

Scrollt denn inzwischen eine Listbox mit 100.000 Einträgen flüssig (mal unabhängig von der Sinnhaftigkeit ungefilterter großer Datenmengen)?

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

Wenn es schnell und flüssig geht, welcher Aufwand muss dafür inzwischen betrieben werden.

(Mit XE3 war das quasi nicht machbar.)

Weil man weder unter VCL noch FMX 100.000 in einer Listbox darstellen sollte?
Oder weil man ab 200 Einträgen eine ListView nehmen sollte?
Oder weil man NIE 100.000 Einträge in einem visuellen Kontroll braucht?

Die Fragestellung ist schon falsch...

[Mavarik]

Zitat von Fritzew:

Also Crossplattform ist es in meinen Augen nicht. Was da fehlt ist opengl unter Windows.

Was hat OpenGL damit zu tun? Welche Engine benutzt wird ist doch letztlich egal...
Es sei den, Du willst manuell etwas machen...
Aber das kannst Du ja trotzdem noch!

Zitat von bra:

Und wieviele hier programmieren Spiele oder Grafikprogramme die als Zielgruppe Anwender mit der "entsprechenden Grafikkarte" haben? Ich lehne mich mal weit aus dem Fenster und behaupt für den Großteil sind eher Businesskunden die Zielgruppe und da sind Grafikkarten wohl so ziemlich das Letzte, was in einem PC eine Priorität hat.

Es muss ja kein Spiel sein, aber welcher Rechner hat den heute keine GPU auf der Grafikkarte?

Lassen wir mal die billig Dingen mit VRAM im real RAM weg...

[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

[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.