FMX = Spiele-Engine in schlecht?

[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 ;-)

[Popov]

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.

[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! :stupid:

[stahli]

Ich habe das gestern noch etwas umgebaut:

Das Formular wird jetzt im Mainthread fortlaufend aktualisiert - mehr passiert dort nicht mehr.

Die "Businesslogik" (die vorliegend nur die Positionen der "Panels" neu berechnet) ist jetzt in einem Objekt gekapselt und läuft in einem eigenen Thread.

Die VCL-Controls senden nur "Anweisungen" an die Buisinesslogik (BL), z.B. wird dort der Wert für Sleep geändert, der die Geschwindigkeit der BL regelt.

Insofern erfolgt die Neuzeichnung des Formulars ständig gleich schnell und die Geschwindigkeit der sichtbaren Verschiebungen hängt nur vom Ablauf der Neuberechnungen in der BL ab (also vom Sleep-Wert).

Wenn man Sleep runter regelt sieht man, wie fix die Änderungen erfolgen können. Es ist dabei schon ein Unterschied zwischen meinem privaten (schnellen) und meinem dienstlichen (langsamer) Rechner zu sehen.

Das Ganze ist noch nicht der Weisheit letzter Schluss, aber die Grundausrichtung finde ich nicht schlecht.

Letztlich will ich zu einer Lösung komplett ohne VCL (also ohne Bitmaps und Canvas) kommen. Offenbar führt die VCL zu verschiedenen Problemen wenn die Anzahl der Zeichenaktionen zu iel wird.

Z.B. habe ich einen kleinen "AniIndicator" gebaut, der sich fortlaufend neu zeichnet. Dabei zerhaut irgend etwas die Bitmaps. Offenbar verkraftet die VCL die Überbelastung nicht bzw. kommt dann mit der Formularsyncronisation nicht klar.

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

Falls wer das Thema reizvoll findet und mitrödeln will... sehr gern! Einfach melden!

[Daniel]

Macht es Sinn, an dieser Stelle ein eigenes Thema zu eröffnen? Denn mit "Firemonkey" bzw. "Spiele-Engine" hat die aktuelle Entwicklung ja wenig zutun, wenn ich das richtig sehe.

[Memnarch]

Praktisch wäre auch vllt soetwas wie "SHared-COntext"(so würde ich das mal nennen)

wenn du nämlich sowas hast:

Form
--Frame
----Panel
----Panel
----Frame
--Frame
----Panel
------Panel
------Panel

Gbts eine ziemliche verschachtelung an "Bitmaps"(Setze hier ein, was immer du mal nutzen willst).

Für große Applikationen der Tod würde ich mal behaupten.
An der Stelle müsste man halt dann doch bestimmen können, das die Frames jeweils nen Zeichenkontext haben und die childs sich direkt dort draufzeichnen.
Kommt man halt nicht drumherum :|