FMX = Spiele-Engine in schlecht?

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

**Namenloser**

Also falls du OpenGL verwenden willst kann ich dir aus eigener Erfahrung nur folgenden Tipp geben: Geh davon aus, dass Context-Switches *extrem* langsam sind. Ein Context-Switch ist z.B. wenn du erst auf Bitmap A zeichnest und dann auf Bitmap B.

Bei mir ging es in einer Schleife immer abwechselnd, und ich hatte mir keine Mühe gemacht, das zu optimieren, weil ich davon ausgegangen war, die Treiber wären bestimmt intelligent genug, das zu optimieren – wenn die Hersteller schon Hacks in ihre Treiber einbauen, nur damit bestimmte Benchmarks schneller laufen, dann werden sie doch sowas nicht weglassen, wo doch selbst Festplatten schon NCQ haben, oder? Nun, es stellte sich raus, sie sind es nicht, und so war die „hardwarebeschleunigte“ Darstellung am Ende langsamer als das CPU-Rendering. Ich habe das zwar im Nachhinein noch etwas hinbiegen können, aber es war dann eher eine Frickellösung. Inzwischen habe ich angefangen, eine neue Engine basierend auf diesen Erfahrungen zu schreiben... die Entwicklung wird allerdings jetzt seit Monaten davon blockiert, dass ich eine Lösung bräuchte, Polygone in Dreiecke zu zerlegen, und momentan nicht wirklich die Zeit habe, mich damit genauer auseinanderzusetzen

Was ich sagen will: Berücksichtige die Einschränkungen von Grafikkarten schon ganz am Anfang im Entwurf, denn es ist schwierig, das im Nachhinein umzuändern.

Bei der Diskussion stellt sich die Frage auf was die Engine später können soll. Denn aus eigener Erfahrung weiß ich, dass für ein Game wie Space Invaders keine besondere Mühe machen muss. Früher vielleicht, aber die heutigen Rechner bügeln das alles aus. Die 1000 kleine Bitmaps kriege ich locker über die Canvas bewegt, ohne das es flackert.

Anders sieht es aus wenn man etwas anspruchsvolles machen will. Dann muss man alles was unnötig ist ausklammern. Deshalb die Frage - was soll die Engine später können.

**jaenicke**

Das Problem Out-Of-Memory dürfte von den offenen Handles herrühren. Ich hatte so etwas ähnliches auch schon gemacht. Da habe ich dann genau aus dem Grund nicht für jedes Element ein Handle (z.B. TBitmap, TCanvas, ...) geöffnet.

Ich habe allerdings die OS-Funktionen wie Mapping von Views usw. mit benutzt um gedrehte Inhalte usw. direkt zu zeichnen usw.

So liefen auch mehrere tausend gut.

**stahli**

Also mein Wunsch:

- Optik wie VCL Style oder besser FMX Style incl. Effekten und Schatten ist völlig ausreichend.
- Dinge wie Lichteffekte und 3D wären Schmankerl, müssten aber nicht sein.
- Der Anwender bedient das Programm und auch bei aufwendigen Berechnungen werden Fortschritte eines AniIndicators (drehende Sterne oder Punkte), einer Progressbar oder eines Gitters bei Datensatzwechseln flüssig, verzögerungsfrei und flimmerfrei dargestellt.
- Ich will also auf ein Application.Processmessages verzichten.
- Der AniIndikator soll laufend vor sich hin wackeln wie ein Baum im Spiel, egal was ich in der Anwendung tue. Das ist eigentlich das, was man m.E. ohne negative Vorerfahrungen mit der VCL auch erwarten würde. (Wobei ich natürlich einsehe, dass vor 20 Jahren noch ein anderer Stand der Technik vorherrschte.)
- Wenn ich in meiner Anwendung in Zeile 500.000 schreibe: "Panel1.Left := Panel1.Left + 1" dann will ich die Änderung im Formular auch sehen, wenn ich diese Zeile mit F8 ausführe. Dazu darf die Formularänderung nicht im gleichen Thread laufen wie der Rest der Anwendung.
- Die Funktionalität sollte möglichst auf allen Windows-Versionen ab XP und mit allen möglichen Grafik-Hardwaren gegeben sein.
- Funktionalität auf MAC und mobilen Plattformen wäre natürlich nicht falsch.

Das alles habe ich mir auf Grund der schönen bunten Emba-Videos von FMX erwartet. Im Nachhinein weiß ich, dass ich da ... ma sagen ... äh ... einem Missverständnis auf den Leim gegangen bin.
Nichts desto trotz halte ich die Zielstellung für legitim und im Grunde wohl auch realisierbar.

Ob das Ganze hardwarebeschleunigt laufen muss, glaube ich noch nicht mal. So eine Formularanwendung ist ja doch ziemlich einfach gestrickt, auch wenn man Transparenz, ein paar Styles und Skins verwendet. Es kommt (denke ich) mehr auf eine sinnvolle Optimierung an und auf eine Formularaktualisierung in einem eigenen Thread. Ich denke, das ist der Knackpunkt.

Wer schon mal CodesiteLogging genutzt hat - das ist ein schönes Beispiel. Die Logs werden schnell an eine unabhängige Stelle (LogManager, sage ich mal) geschickt und die Anwendung kann normal weiter laufen. Im LogManager werden die Infos dann aufbereitet und nach und nach ausgegeben.

So ähnlich sollte die Formularaktualisierung laufen. Die Controlabbilder werden nach und nach auf die Formularfläche kopiert und die entsprechenden Regionen vermerkt. Anschließend werden Maus- und Tastaturereignisse geprüft und an die Controls weiter gegeben, die sich unter der Maus befinden oder den Focus haben...

Das hätte ich gern und das würde m.E. völlig neue Möglichkeiten und Anwendungen ergeben.

FMX hat ja leider auf ganzer Linie mehr als enttäuscht.

Ich selbst will eigentlich erst mal nur etwas auf dem Gebiet lernen um etwas Hintergrundwissen zu sammeln.

@jaenicke
Genau. Bitmap und Canvas habe ich jetzt nur der Einfachheit halber auf die Schnelle verwendet. Ich denke, dass das auch schlanker gehen müsste. Gedrehte Controls und Zuweisung von Schatten oder Effekten wäre natürlich auch super. Insofern wären schon komplexere Zeichenfunktionen wünschenswert. Aber lösbar sollte das sein (wenn auch nicht unbedingt für mich, so ohne Vorkenntnisse).
Kann man mal was von Deinem Geraffel sehen?

@all
Die Frage auch an alle anderen: Wer irgendwelche Teilergebnisse, Exen, Bilder, Videos oder Kenntnisse zu diesem Thema vorzeigen kann ... ich würde sofort alles begierig aufsaugen!

**jaenicke**

Zitat von stahli:

@jaenicke
Insofern wären schon komplexere Zeichenfunktionen wünschenswert. Aber lösbar sollte das sein (wenn auch nicht unbedingt für mich, so ohne Vorkenntnisse).
Kann man mal was von Deinem Geraffel sehen?

Ich kann mal die Technik dahinter erläutern. Der Code gehört der Firma, den kann ich nicht einfach posten. Mal schauen, wann ich dafür Zeit finde.

Zitat von stahli:

Der Grundgedanke der Komponentenzeichnung im Hintergrund und des späteren Zusammenbaus des Formulars mit den fertigen Bausteinen gefällt mir aber. Ich werde mich wohl mal mit OpenGL befassen (müssen).

Die Hardwarebeschleunigung ist genau der Grund weshalb die Oberfläche von z.B. Vista oder 7 so viel flüssiger läuft als die von XP (vorausgesetzt man macht nicht den Fehler und deaktiviert Aero).
Seit Vista übernimmt das Rendern (inkl. Überlappungen usw.) die Grafikkarte statt der CPU, sofern das möglich und Aero aktiv ist.