FMX = Spiele-Engine in schlecht?

[jaenicke]

Windows 8.1

Zitat:

Zitat von stahli (Beitrag 1233234)

- wird das grüne Rechteck gezeichnet und bleibt es nach Abschluss sichtbar?

Ja, wird es und es verschwindet beim Neuzeichnen, also ganz normal wie bei der VCL auch.

Zitat:

Zitat von stahli (Beitrag 1233234)

- läuft der AniIndikator während Button1 + 2 weiter?

Nein, aber das lässt sich mit Application.ProcessMesaages ändern.

Zitat:

Zitat von stahli (Beitrag 1233234)

Dann interessiert mich auch, ob es nach Kompilierung unter XE4 oder 5 Änderungen im Verhalten gibt.
Vielleicht kann sich das ja mal jemand antun... :roll:

Unter XE5 ist es exakt genauso.

[rweinzierl]

windows 7

Kein Grünes Rechteck

Beep nach 2 Sekunden

Animation läuft nicht weiter

[jaenicke]

Wobei ich mich frage warum man das unter FireMonkey so machen sollte. Dafür gibt es ja eigentlich alles fertig ohne Code. Beispiel:
Anhang 40069

[stahli]

Ich nutze das, um während dem Debuggen berechnete virtuelle Positionen anzuzeigen.
Controlverschiebungen auf einem Formular wären ja bei F7 noch nicht darstellbar - außerdem werden die real erst später verschoben.

Letztlich habe ich nur nicht verstanden, warum die Nutzung dieses Konzeptes systemabhängig ist. M.E. kein gutes Zeichen...

(Deine verlinkte Demo läuft übrigens unter XE3 noch nicht. Das unterstützt mich in meinem Vorhaben, nochmal klar nach einem Bugfix/Update zu fragen, ohne XE5 kaufen zu müssen.)

[mirage228]

Zitat:

Zitat von stahli (Beitrag 1233234)

- wird das grüne Rechteck gezeichnet und bleibt es nach Abschluss sichtbar?

Ja, wird es und bleibt es. Nen kleiner Bereich in der Ecke bleibt aber frei.

Zitat:

- wenn nicht, dauert Button1 trotzdem 2-3 Sek (bis zum Beep)?

Beep kommt auf jeden Fall.

Zitat:

- läuft der AniIndikator während Button1 + 2 weiter?

Nope, aber Application.ProcessMessages sollte schon mal was bringen.

System ist Windows 7 Professional x64. Grafikkarte ist ne nVidia GeForce GTX 670.

[stahli]

Hast Du die Glasframes an?
Unter Win7 hat es sonst offenbar nicht funktioniert.
Vielleicht liegt es aber auch an der Grafikkarte.

[mirage228]

Zitat:

Zitat von stahli (Beitrag 1233312)

Hast Du die Glasframes an?
Unter Win7 hat es sonst offenbar nicht funktioniert.
Vielleicht liegt es aber auch an der Grafikkarte.

Japp, Aero ist voll aktiviert mit allen Effekten (Fenster-Transparenz etc.). Mit dem "Windows Basis"-Theme klappt es auch.
Mit "Windows klassisch" (Windows 2000-Style) kommt allerdings kein grüner Kasten...

[jaenicke]

Zitat:

Zitat von mirage228 (Beitrag 1233314)

Mit "Windows klassisch" (Windows 2000-Style) kommt allerdings kein grüner Kasten...

Das macht irgendwo auch Sinn, dass sich das anders verhält. Denn bei klassischem Layout ist was das Zeichnen des gesamten Fensters angeht keine Hardwarebeschleunigung involviert. Das ist ja der Grund weshalb sich die GUI insgesamt bei XP deutlich langsamer angefühlt hat als bei Windows 7 und 8. Das Zeichnen der Fenster muss da die langsamere CPU übernehmen.

Da bei Firemonkey allerdings für den Clientbereich die Hardwarebeschleunigung aktiviert ist, sollte das dafür zwar keine Rolle spielen, aber damit zu tun wird es haben.

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

[Popov]

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.