FMX = Spiele-Engine in schlecht?

[Der schöne Günther]

Zitat von stahli:

Kann jemand beide Framework-Konzepte (FMX und SpieleEngines) grundsätzlich vergleichen und Parallelen und Unterschiede erklären?

Ich persönlich kenne leider nur das eine, nicht das andere (FireMonkey)

Deshalb weiß ich nichts von Designschwächen, wundere mich aber, was bei der Performance das Problem sein sollte? Wenn FM im Grunde doch auch auf schwachen Mobilgeräten laufen soll? Gibt es auf FireMonkey-Oberflächen bestimmte Dinge welche besonders stark Performance fressen?

Echtzeit 3D-Visualisierungen (und da gibt es neben Spielen eine Menge Anwendungsgebiete wie CAD, VR und Datenvisualisierungen) beziehen ihre Grafikqualität in der Regel von der Rohleistung des Grafikchips: Hier sind es in der Regel diskrete Drahtgittermodelle auf die Bitmaps geklebt werden. Weiterhin extrem parallelisierbare "Shader"-Programme die sich um die Schattierung, Animation und andere "Effekte" des Bildes kümmern. Letztendlich die Übertragung auf ein (oder mehr) zweidimensionale Pixelbilder mit ganzzahligen Koordinaten. Soviel nur zur Rendering-Pipeline, von anderen Gebieten wie Physik, KI oder Scheduling für das Nachladen von Inhalten zur Laufzeit ganz zu schweigen

Für eine normale 2D-GUI fallen Dinge ausgefallene Shader-Effekte und hochauflösende Drahtgittermodelle direkt flach, im Endeffekt haben wir hier für das Rendern viel weniger Arbeit. Für das Rendern. Eine allgemeingültige, funktionierende, auf mehreren Betriebssystemen funktionierende GUI muss natürlich um einiges mehr können, als eine Handvoll vorgefertigte Grafikelemente auf dem Bildschirm anzeigen und eventuell merken, wenn jemand eine Taste drückt oder einen Mauszeiger darüber schiebt.

Ist die Rendering-Performance wirklich schlecht? Auf allen Systemen?

Zitat von CHackbart:

Ich habe dabei 2 Varianten entwickelt, die erste war in reinem Firemonkey Code und die zweite Variante reines Opengl. Die CPU Last in ersterem beträgt 40% und bei OpenGl knapp 1%.

Gerade das zeigt doch dann, dass es nicht das pure Rendering an sich ist, sondern irgendwo anders Performance verballert wird, oder?
Ich weiß noch nichts von FireMonkey, aber irgendwo anders wird man sich einen Flaschenhals gebaut haben...


Ich bin trotzdem gespannt und hoffe irgendwann einmal die Zeit zu haben, FireMonkey auszuprobieren. Das einzige was ich von FM weiß ist dass es angeblich voll vektorbasiert ist und angeblich auf allen Plattformen wunderbar läuft

[CHackbart]

Zitat:

Gerade das zeigt doch dann, dass es nicht das pure Rendering an sich ist, sondern irgendwo anders Performance verballert wird, oder?

Da hast du Recht es sind mehrere Ursachen die alle zusammen zu einer schlechten Performance führen. Ich denke mal der Hauptaugenmerk bei den meisten Delphi Anwendungen liegt in der Entwicklung von Datenbankanwendungen und auch wenn man sagt es sollten keine Tabellen mit mehreren hundert Einträgen verwendet werden, mit der Begründung das dies eh kein Mensch liest, so sollte doch zumindest die Tabelle in der Lage sein diese Daten darzustellen. Das gleiche gilt für TListview und TTreeview Komponenten. Vor ein paar Tagen gab es mal einen Post hier im Forum bezüglich TTreeview. Zumindest in XE2 wurde jede Expand-Änderung eines Eintrags an jedes darunter liegende Node rekursiv übergeben und diese wurden ALLE neu gezeichnet. Im ungünstigsten Fall hast du dort mehrere hundert Elemente die dann einfach neu gerendert werden. Selbst wenn jemand so einen derartigen Code im Blindflug und unter massiven Zeitdruck erstellt, das machen wir ja alle ab und zu, dann sollte man doch im Betatest darauf aufmerksam werden. Ich denke mal Listen und Baumansichten gehören definitiv zu Kernkomponenten die auch bis zum Exzess getestet werden sollten.
Außerdem bauen ja alle 2D-Elemente auf die Canvasklassen auf die zumindest in XE2 (wie gesagt ich kann nur über XE2 reden, da ich XE4 nur als Demoversion testen wollte und *erm* naja in der Testzeit nach der Installation nur einmal kurz damit "gespielt" habe) extrem unperformant sind. Prinzipiell kann man eine TCanvasklasse bauen die z.B. komplett OpenGL nutzt. Das würde zumindest einen Großteil der Geschwindigkeitsprobleme beheben.

Christian

[Der schöne Günther]

Zitat von CHackbart:

so sollte doch zumindest die Tabelle in der Lage sein diese Daten darzustellen. Das gleiche gilt für TListview und TTreeview Komponenten. Vor ein paar Tagen gab es mal einen Post hier im Forum bezüglich TTreeview. Zumindest in XE2 wurde jede Expand-Änderung eines Eintrags an jedes darunter liegende Node iteratiov übergeben und diese wurden ALLE neu gezeichnet

Ja, ich glaube, ich sehe wohin die Reise geht.

[stahli]

Ich habe ja (sicher bekannter maßen) mein Gitter auf einem TFmxObject aufgebaut und die darin enthaltennen Zellen ebenso.

Das ging teilweise extrem langsam. Einige Flaschenhälse habe ich versucht, notdürftig zu flicken. Ein grundsätzliches Verständnis für eine umfassende Problemlösung fehlt mir aber.

Einige Dinge, die mir aufgefallen sind:

Das Gitter wird immer mindestens 3 mal hintereinander gezeichnet. Es sind aber nicht immer exakt 3 mal, sonst könnte ich ja einfach Nr. 2 und 3 auslassen. In gewisser Weise ist das mehrfache Zeichnen vielleicht verständlich, wenn sich enthaltene Controls ändern und deshalb der Parent angepasst werden muss - aber bei Zeichnung 2 und wenigstens 3 liegt das eigentlich nicht vor.

BringToFront und SendToBack von Zellen führt zum (mehrfachen?) Neuzeichnen aller Controls durch PaintChildren.

Das Zuweisen von Effekten (Schatten) ebenfalls.

Auch das Zuweisen einer gleichen Position eines Controls (also einer Neuberechnung ohne eine Änderung der Position) führt zu PaintChildren.
Daher berechne ich das neue Rect und weise dieses nur bei bestehenden Änderungen zu.


(Das nur mal als ungefährere Schilderungen, ohne dass ich gerade die Quellen vorliegen habe. Ich brauchte viele unterschiedliche Versuche bis ich teilweise Verbesserungen erreichen konnte.)



Wie CHartbart sagt, bei einer Entwicklung des Frameworks und Testen mit 5 Controls fallen solche Engpässe nicht auf. Aber über das Stadium sollte FMX eigentlich weg sein.

[Namenloser]

Zitat von stahli:

BringToFront und SendToBack von Zellen führt zum (mehrfachen?) Neuzeichnen aller Controls durch PaintChildren.

Das Zuweisen von Effekten (Schatten) ebenfalls.

Da wundere ich mich spontan aber trotzdem, dass das zu Performanceproblemen führen soll, denn immerhin ist die Darstellung ja hardwarebeschleunigt. Jede Grafikkarte schafft es heute locker, einige tausend Sprites mit 60fps flüssig darzustellen. Ich glaube nicht, dass du tausend Controls auf deiner Form hast...

Da scheint schon noch irgendwas anderes schiefzulaufen.

[stahli]

... müsste ich zu Hause nochmal nachvollziehen, wo das genau geklemmt hatte.


Ein leicht nachvollziehbares Problem düften Counterdarstellungen in einem Label oder eine flüssig laufende Progressbar sein.

Zu letzterem gab es mal einen Hinweis im Forum, den ich mir irgendwo notieren wollte, habe das aber gerade nicht mehr auf dem gedanklichen Zettel.

Jedenfalls: Einfach nutzen und Spaß haben geht definitiv nicht. Im Gegenteil, manche Änderungen der GUI werden real gar nicht sichtbar.
Und genau die flüssige und perfekte Darstellung (wie eben in Spielen üblich) hatte ich bei FMX eigentlich ursprünglich erwartet (vielleicht von kleinen Kinderkrankheiten abgesehen).

[Namenloser]

Wollte ich im letzten Beitrag schon verlinken, hatte aber den Link nicht gefunden: The FMX enumeration anti-pattern. Vermutlich sind es solche Sachen, die Firemonkey so lahm machen.

Falls jemand nur den Anfang liest:

Zitat:

‘Now now’, you might say, ‘no need to play high and mighty over a quick demo from a Developer Relations guy!’ And indeed, if this problem extended no further than a quick demo from a member of Developer Relations I would agree. However, if you browse the FMX source code, you will find this anti-pattern repeated again and again. Ever wondered why large menus in FMX can be so damn slow, even when it is the native menu bar being used? Wonder no more.

[BUG]

Zitat von NamenLozer:

Jede Grafikkarte schafft es heute locker, einige tausend Sprites mit 60fps flüssig darzustellen. Ich glaube nicht, dass du tausend Controls auf deiner Form hast...

Ich habe irgendwie die leise Vermutung ("vektorbasiert"), dass Controls aus mehr als nur ein paar Vertices (~ein Sprite) besteht*. Die heutige Grafikleistung kommt am PC mehr oder weniger nur zum Tragen, wenn das meiste Zeug schon im Speicher der Grafikkarte liegt.

Das für ein flexibles Komponentensystem hinzubekommen stelle ich mir reichlich kompliziert für. Man denke nur an Events wie onPaint.

* Ich habe weder mit FMX gearbeitet, noch in in den Code geguckt => wilde Vermutung

[Der schöne Günther]

Wenn es überhaupt nur annähernd rein an der Grafikkarte liegen würde, wäre es nicht die CPU-Last, die so hoch ist. Mit Direct2D kenne ich mich nicht aus, aber beim Konvertieren und Schieben der Daten auf die Grafikkarte kann man auch nicht allzu viel falsch machen können.

Dinge aus dem Beispiel wie das ungeschickte Wandern durch die Liste werden eher das Problem sein. Bei kleinen Beispielen fällt so etwas performance-mäßig nicht auf, aber im Praxis-Alltag schon.

Dass das genannte Beispiel mit XE3 allerdings ausgemerzt wurde ist doch ein gutes Beispiel, oder? Es kann eigentlich nur besser werden. Die VCL lief an Tag 1 sicherlich auch nicht 100%ig rund...

[stahli]

Da ich das Thema interessant und in Bezug auf FMX auch wichtig finde habe ich mal einige Tests und Überlegungen angestellt.

Video: http://youtu.be/TNpaI2D_nqE
Anlage: Testprojekt (nur Quellen für XE3)

Im Grunde läuft meine Überlegung darauf hinaus, dass nicht ständig alle Controls neu gezeichnet werden müssen sondern zu jedem Control ein Bitmap verwaltet wird, das bei Bedarf neu auf die (das, den?) Canvas kopiert wird. Nur wenn sich das Control selbst ändert (Status, Größe, o.ä.) muss es tatsächlich neu gezeichnet werden. Ansonsten reicht es, das einmal erzeugte Abbild auf das Formular zu kopieren.

So sollten Änderungen auf dem Formular schnell und jederzeit dargestellt werden können und das auch im Debugmodus.
Eine ständige (echte) Neuzeichnung aller über- und untergeordneter Controls könnte vermieden werden.

Die Entscheidung, welche Control-Abbilder neu auf das Formular kopiert werden müssen, könnte das Framework unabhängig von den Zeichenmethoden der Controls entscheiden.

Diese Aktion wäre auch unabhängig vom Mainthread jederzeit möglich (auch im DebugModus).

Ich weiß, dass das etwas ... äh ... unscharf klingt, aber ist das ungefähr verständlich und plausibel?


Man könnte alle Control-Änderungen sofort auf dem Formular sehen.
Es würde eine gewisse Trennung der Control-Zeichenroutinen und der tatsächlichen Formularzeichenfläche geben.