FMX = Spiele-Engine in schlecht?

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

[Popov]

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.

[stahli]

@Daniel
Ich würde gern noch hier bleiben, weil ich noch bei der Idee der gepufferten Bitmaps bleiben will.
Wenn Du das verschieben willst ist das natürlich auch ok (in meinen neuen OpenGL-Thread passt es aber auch nicht besser).

@all
Anbei nochmal eine neue Testversion.
Die GUI wird im Mainthread gezeichnet. Die Businesslogik läuft in einem eigenen Thread. Dort erfolgen die Positionsänderungen usw.
Die Geschwindigkeit des Threads kann über den Sleepwert geändert werden.
Eine echte Anwendung würde man natürlich ohne Sleep laufen lassen. Da würden ja normalerweise keine Controls verschoben.

Wenn man die VCL-Schleife startet, dann hängt die Anwendung natürlich so lange.

Die Test-Schleife vom unteren Button läuft im Business-Thread. Die Geschwindigkeit ist vom Sleepwert abhängig.
Der Zahlenwert in den Controls zeigt den Schleifenzähler an.

Die Controls zeichnen sich jetzt bei jedem Frame neu. Es gibt also keine Bitmaps zum puffern mehr.
Das Ganze läuft trotzdem sehr schnell (bei der einfachen Grafik). Bis 10.000 Panels läuft das flüssig, danach wird es hakelig.

Der Flaschenhals bei FMX dürfte also wohl nicht mit Bitmappuffern zu verbessern sein, wie ich ursprünglich meinte.
Was aber wichtig ist, ist bei Controländerungen nicht rings herum ständige Neuzeichnungen auszulösen.


Ich habe drei neue Controls gebastelt: AniIndicator, Progressbar, Edit.
Die sind natürlich nur mal schnell angetestet.
Der AniIndicator läuft ständig vor sich hin. Die Geschwindigkeit ist einstellbar.
Die Progressbar kann mit der Maus eingestellt werden und läuft dann automatisch auf null zurück. Beide sind verbunden (ist natürlich hier kein echtes Binding )
Die Edits können einen Fokus erhalten und Zeichen annehmen (sonst geht da noch nix - also kein Cursor, kein Select, kein Löschen usw!). Um das weiter auszubauen wäre natürlich einige Arbeit notwendig.

Die VCL-Controls sind natürlich hier nur für Testzwecke. Real könnte man auf VCL-Controls verzichten (wenn es ausreichend Alternativen gäbe).


Warum nun das Ganze?


So richtig habe ich keine Ahnung!

Die VCL und FMX will ich nicht mehr gern verwenden. Die sind einfach nicht angenehm, stabil und flüssig zu händeln.

Die Demo gefällt mir vom Handling schon ganz gut.
Man hat eine flüssige GUI, die unabhängig vom Businessthread läuft, der in einem Objekt gekapselt ist.
Die Windowsereignisse spielen dann eigentlich keine Rolle mehr, außer dass das Formular diese abfängt und an die GUI übergibt.
Die GUI-Controls können direkt in die Businesslogik gebunden werden.

Ich habe jetzt m.E. einen Ablauf, wie er auch mit OpenGL o.ä. funktionieren würde - natürlich auf ganz anderem Niveau.

Wenn ich das Projekt schrittweise debugge, dann werden Änderungen natürlich wie bei der VCL auch nicht sichtbar, da die Formularaktualisierung im Mainthread läuft. Evtl. könnte man den Formularcanvas einer fremden Anwendung kapern, so dass man Formularaktualisierungen so beim Debuggen erkennen könnte.


PS: Jetzt gehe ich erst mal ins´ Bettchen - vielleicht bin ich morgen schon schlauer.

[jaenicke]

Zitat von stahli:

Wenn ich das Projekt schrittweise debugge, dann werden Änderungen natürlich wie bei der VCL auch nicht sichtbar, da die Formularaktualisierung im Mainthread läuft. Evtl. könnte man den Formularcanvas einer fremden Anwendung kapern, so dass man Formularaktualisierungen so beim Debuggen erkennen könnte.

Du brauchst nur Delphi auf den zweiten Monitor verschieben zum Debuggen und in Strg + F7 einfach Application.ProcessMessages auswerten, schon werden die Fenster des debuggten Programms aktualisiert...

[Zacherl]

Vollkommen wegkommen von den Windows Events wirst du nicht, wenn du deine Zeichenvorgänge korrekt umsetzen willst. Dazu musst du nunmal zwangsweise auf die WM_PAINT reagieren (wenn du nicht auf gut Glück periodisch alles neu Zeichnen willst).
Dass alle Windows Messages in einem einzigen Message Loop (bei Delphi im "Main-Thread") empfangen werden, kann man als Vor- oder auch als Nachteil sehen. Klar blockiert eine Schleife von 1..10000 dann natürlich erstmal den Empfang weiterer Nachrichten, weshalb dann auch die GUI nicht mehr aktualisiert wird, oder Button Click Ereignisse nicht sofort umgesetzt werden. Auf der anderen Seite kannst du dieses Verhalten recht einfach beeinflussen, indem du (wie von jaenicke schon erwähnt) ein Paar Application.ProcessMessages Aufrufe einstreust (oder System-nah direkt PeekMessage, TranslateMessage, DispatchMessage).

Zu den Neuzeichnungen .. nehmen wir an ich habe folgende Hierachie:

• Form
  • Button1
  • Button2
  • Panel1
    • Button3
    • Button4

Gehe ich hier mal generell von der Möglichkeit aus, dass eine Komponente semitransparent ist, so muss in jedem Falle alles was darunter liegt neu gezeichnet werden. Im "schlimmsten" Falle würde eine Änderung von Button3 also ebenfalls das Panel und das Formular neu zeichnen. Analog dazu muss natürlich bei einer Änderung des Panels sowohl das Formular (falls das Panel z.b. semintransparent ist oder einen AlphaChannel hat), als auch die darüberliegenden Buttons 3 und 4 (in jedem Falle; da diese ggfls. durch das Neuzeichnen des Panels teilweise überdeckt werden) neu gezeichnet werden.

Man sieht also recht schnell, dass diese Zeichenlogik keine triviale Sache ist und dass man in gewissen Fällen halt einfach nicht um ein Neuzeichnen herumkommt. Optimieren kann man hier z.b. indem man jedem Control ein Flag zuweist, welches angibt, ob die Komponente semitransparent ist oder nicht. Dann spart man sich ein paar Zeichenoperationen von darunterliegenden Controls (macht die VCL soweit ich gesehen habe auch so).
Falls das Zeichnen ansich wirklich ein Flaschenhals sein sollte, kann man natürlich auch das "Bitmap Caching" (mindestens GDI+, weil hier zwingend Transparenz / AlphaChannel benötigt wird) verwenden. Ich wage allerdings mal zu behaupten, dass die Zeichenoperationen in der Regel schneller sind, als die ganze Cache Geschichte.
Auch wichtig ist, dass man exzessiven Gebrauch von Clipping macht und somit wirklich immer nur die Teile aktualisiert, die sich wirklich geändert haben und nicht wild drauf los das komplette Control. Im Hintergrund gehe ich zwar davon aus, dass sich ein Control IMMER komplett neu zeichnet, aber die GDI (oder zumindest mal DirectX, OpenGL) sollten die Zeichenoperationen entsprechend des Clippings optimieren, was sich dann wohl in einer kleinen Performancesteigerung sichtbar macht.