FMX = Spiele-Engine in schlecht?

**Der schöne Günther**

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**

Ich musste in der letzten Nacht mal noch ein bischen herum spielen...

Anbei mal ein kleiner Versuch, eine eigene alternative "GUI" zur VCL aufzubauen. Ich benutze da nur eigene Objekte und Bitmaps. Auf die VCL wird dort nicht zurück gegriffen (außer auf den Canvas der TBitmaps zur Vereinfachung).

Ich habe "Panels" gebaut, die sich selbst zeichnen können und dafür eine Bitmap verwalten.

Wenn ein Panel gezeichnet wird, wird ein Zähler incrementiert und der Wert im Panel gezeichnet.

Ist ein Panel unter der Maus wird dessen Rahmen gelb gezeichnet (und der Zähler entsprechend erhöht). Ist es nicht mehr unter der Maus wird der Rahmen wieder schwarz (und der Zähler erhöht).
Panel.Paint wird also nur ausgeführt, wenn das Panel selbst sich ändert (nicht, wenn sich dessen Position ändert).

Wird ein Panel angeklickt wird es blau dargestellt und lässt sich mit der Maus verschieben.

Wenn ein Panel nie unter die Maus (bzw. Mauscursor) kommt, wird es nur ein mal gezeichnet (Text bleibt bei „1“).

Ein Timer kümmert sich darum, die Bitmaps der der Panels regelmäßig auf den Formularcanvas zu kopieren und auf die Mausereignisse zu reagieren.

Man könnte leicht eine AniKomponente bauen, die zyklisch ihr Aussehen (also ihr Bitmap) ändert und das würde dann laufend dargestellt werden, ohne dass die anderen Panels sich dadurch neu zeichnen.

Mir ist es in der Nacht aber nicht mehr gelungen, die "Formularaktualisierung" (TssCanvasForm.Paint) von dem Timer in einen Thread zu schieben, so dass dies zyklisch und unabhängig vom Mainthread passiert (hatte aber nur schnell einen anonymen Thread versucht, bei dem die Syncronisierung so nicht funktionierte).

Deshalb mal ein paar Fragen an die Weisen unter Euch:

Hat jemand eine Meinung, wie man so etwas besser aufbaut?
Sollte man OpenGL verwenden?
Wie wäre es grundsätzlich, wenn die GUI auch auf einem MAC oder mobilen Geräten laufen soll (ich frage hier nur für ein besseres theoretisches Verständnis

)?
Sollte man die Formularaktualisierung im Mainthread machen und nur das Erstellen des Gesamtbildes (zyklisch in einem Thread berechnen)?
Oder sollte man auf Threads verzichten?

Grundsätzlich finde ich es erstaunlich, dass ich innerhalb von ca. 3 Stunden mit ein paar Zeilen Quelltext zu dem vorliegenden Ergebnis gekommen bin.
Da ist natürlich nichts optimiert, ich wollte ja nur mal schauen, ob ich überhaupt zu einem brauchbaren Ansatz komme.

Nachtrag zum besseren Verständnis:
Ich möchte erreichen, dass sich die Controls lediglich neu zeichnen müssen, wenn sie sich selbst (bzw. ihr Aussehen) ändern und nicht ihre Position.
Außerdem möchte ich, dass diese Änderungen jederzeit und sofort auf dem Formular sichtbar werden - auch wenn im Mainthread gerade irgendwelche Berechnungen laufen.
So könnte ein AniIndicator wirklich flüssig laufen, eine Änderung in einer Progressbar sofort und flüssig dargestellt werden und ein unnötiges Neuzeichnen aller Formularcontrols vermieden werden.
Wenn diese Form der Darstellung in der IDE erfolgen würde, könnte man entsprechende Änderungen sogar beim schrittweisen Debuggen einer Anwendung sehen.
Ich wüsste nicht, was grundsätzlich dagegen sprechen sollte - außer dass dies nicht mehr dem bisherigen Konzept entsprechen würde.

Ich hab mir jetzt deinen Code nicht genauer angesehen, aber das Beispiel erinnert mich an etwas was ich auch mal gemacht habe. Auch ich habe damals eine einfach Canvas-Engine gebastelt. Im Grunde habe ich seit langem noch ein Spiel in der Entwicklung (ich sollte es mal endlich fertig kriegen).

Ich bin damals an die Grenzen gestoßen, da ich mit mehreren Tausend Bitmaps hantiert habe. Der Irrtum beruhte auf dem Missverständnis meinerseits, dass eine Bitmap kopieren und eine Rechteck zeichnen und mit Farbe füllen, fast der gleiche Aufwand ist. Denn bem kopieren ist es nur hier lesen, da schreiben. Beim Erstellen ist es da schreiben. Der Unterschied ist dann aber doch gewaltig. Hier eine kleine Statistik:

Ich hatte ähnlich wie du Bitmaps auf der Canvas gezeichnet.

Bei paar hundert Bitmaps (Inhalt: bunte Rechtecke) ging das Ganze noch flüssig voran.

Bei 1000 Bitmaps die gezeichnet wurden, fiel FPS auf etwa 30 und ging immer weiter runter.

Bei knapp 3.000 Bitmaps fiel das Ganze bis etwa 5 FPS runter.

Bei etwas über 3.000 Bitmaps kam Out-Of-Memory. Da bewegte sich alles noch so um 3 bis 5 FPS.

Zum Schluss habe ich also 3.000 Bitmaps/F * 5 FPS = 15.000 Bitmaps pro Sekunde gezeichnet.

Das Gleiche habe ich mit bunten, allerdings gezeichneten Rechtecken versucht. Statt rechteckige Bitmaps zu kopieren, wurden sie hier direkt auf die Canvas gezeichnet. Ansonsten alles gleich.

Die 3.000 Rechtecke waren kein Problem bei stabilen 60 FPS.

Die 30 FPS habe ich bei 10.000 Rechtecken erreicht

Die 5 FPS habe ich bei über 45.000 Rechtecken erreicht.

Zum Schluss habe ich 45.000 Rechtecke/F * 5 FPS = 225.000 Rechtecke pro Sekunde gezeichnet.

Das ist also der Unterschied zwischen bunte rechteckige Bitmaps zeichnen und bunte Rechtecke zeichnen. Die Ergebnisse könnten bei dir ähnlich sein, denn es war fast nur reines zeichnen, keine komplexen Berechnungen dazwischen.

**Namenloser**

Es ist in der Tat immer schwierig, da einen gescheiten Tradeoff zu finden. Ich glaube in der Firefox-Rendering-Engine (Gecko) steckt auch so ein Mechanismus, Layers genannt (zumindest nehme ich an, dass es sowas ist). Mozilla hat da jahrelang dran entwickelt (wird u.a. für die hardwarebeschleunigte Darstellung benötigt), und die haben hunderte Mitarbeiter.

Ich denke, man sollte zumindest nicht jedes einzelne Control cachen. Mal angenommen, man hat z.B. zwei Button in einem Panel, das selber wieder zusammen mit anderen Controls in einem Panel liegt. Dann sollte man vielleicht nicht die Buttons selbst als Bitmap cachen, sondern nur das Panel, auf dem sie liegen, oder vielleicht sogar nur das Panel, auf dem das Panel liegt (oder nur die Buttons cachen aber dafür keins von den Panels).

Dafür müsste man sich irgendwelche Heuristiken überlegen. Z.B. wie viele Untercontrols es gibt, oder man misst die Zeit, die das Zeichnen braucht, und entscheidet basierend darauf, ob es Sinn macht, das Ergebnis zu cachen.

**stahli**

Out of Memory hatte ich bei dem Versuch von 10000 "Panels". Näher eingerenzt hatte ich das in der Nacht nicht mehr.

Ich weiß nicht, ob Bitmaps und die verwendeten Kopierfunktionen das Maß aller Dinge sind. Grundsätzlich kann ich mir aber nicht vorstellen, dass ein Kopieren von Speicherinhalten so sehr langsam sein muss. Bestimmt kann man hier auf schnelle Lösungen umstellen.

Wenn man sich das ständige Neuzeichnen von gestylten Controls vorstellt würde ich schon eher mit erhöhtem Zeitbedarf rechnen.
Gemäß meiner Überlegung könnte man den bunten Button mit Schörkeln und Lichteffekten im Puffer lassen und lediglich den Text neu schreiben, wenn ein neues Caption zugewiesen wird.
Erst wenn der Button gedrückt wird muss auch sein Aussehen (nämlich gedrückt) neu berechnet werden.

Ob man das Konzept ohne OpenGL oder ähnliches brauchbar realisieren kann, weiß ich immer noch nicht. Der Knackpunkt ist wohl, dass selbst das Kopieren des berechneten Gesamtbildes auf die Formularfläche mit dem Mainthread syncronisiert werden muss - und das verhindert dann eben dass die Darstellung von Formularänderungen unabhängig vom Mainthread erfolgen kann (eben z.B. auch nicht während dem schrittweisen Debuggen einer Anwendung).

Evtl. könnte man - mal so als Überlegung - die gesamte Businesslogik in einen eigenen Thread auslagern.
Dann würde der Mainthread sich allein um die Formularaktualisierung kümmern und die Mausereignisse an die Businesslogik geben.

Die Businesslogik (die man ja ohnehin von der GUI trennen sollte) könnte in einem eigenen Thread gestartet werden (TMyBusinesslogic.Start).

Das sind natürlich alles recht unscharfe Überlegungen aber das Thema würde ich gern noch diskutieren und entsprechend lernen...

@Namenloser
Das stimmt. Die Verwendung gleicher "Bitmapmuster" für gleiche Controls gleicher Größe und gleichen Statuses habe ich auch schon als zweckmäßig erachtet.
Als einzelner Programmierer in 3 Stunden habe ich dann ja schon mal ein bissl was erreicht. Wenn meine Firma 100 Angestellte hätte wäre ich aber auch nicht unglücklich

Ich hab den Thread jetzt weiter gelesen (bei meiner ersten Antwort habe ich nur deinen letzten Post beachtet).

Es macht sich manchmal bezahlt einen langsamen Rechner zu haben, denn dann sieht man einiges manchmal in Zeitluppe, was andere gar nicht sehen. So bin ich wohl einer der wenigen Glücklichen auf der Welt die tatsächlich beobachten konnten wie ein Button gezeichnet (zumindest den Anfang). Es begann oben rechts und zeichnete dann Pixel für Pixel das erste Rechteck entgegen dem Uhrzeigersinn.

Aber das ist es nicht auf was ich hinaus wollte (auch wenn es interessant ist), denn was ich auch beobachten konnte ist, dass jedes Objekt einen Clipping Bereich hat. Ist ein Button nicht verdeckt, wird er komplett gezeichnet. Das dauert am längsten. Ist er verdeckt, wird er nicht gezeichnet. Ist er zum Teil verdeckt, wird nur das sichtbare Teil gezeichnet. Windows arbeitet in der Hinsicht also effizient. Selbst ein Fenster mit Buttons wird zuerst so gezeichnet, dass die Bereiche des Fensters auf denen sich die Buttons befinden, nicht gezeichnet werden. Windows zeichnet das Fenster dan sozusagen mit Löchern. Die Löcher werden erst dann gefüllt, wenn die Buttons gezeichnet werden.

Somit ist es nicht verkehrt bei jedem Objekt zuerst den Bereich zu berechnen der sichtbar ist und gezeichnet werden muss (bzw. den schon im Speicher zu haben). Denn warum soll man, wenn man z. B. ein Fenster wie der Notepad.exe es hat, zuerst das leere Fenster zeichnen? Das wird später ja sowieso überzeichnet. Es reicht ha nur den Rahmen und Titelleiste zu zeichnen. Der Rest wird später nachgeliefert.

Ich denke mir so kann man viel Zeit und Rechenleistung sparen.