FMX = Spiele-Engine in schlecht?

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

... müsste ich zu Hause nochmal nachvollziehen, wo das genau geklemmt hatte.


Ein leicht nachvollziehbares Problem düften Counterdarstellungen in einem Label oder eine flüssig laufende Progressbar sein.

Zu letzterem gab es mal einen Hinweis im Forum, den ich mir irgendwo notieren wollte, habe das aber gerade nicht mehr auf dem gedanklichen Zettel.

Jedenfalls: Einfach nutzen und Spaß haben geht definitiv nicht. Im Gegenteil, manche Änderungen der GUI werden real gar nicht sichtbar.
Und genau die flüssige und perfekte Darstellung (wie eben in Spielen üblich) hatte ich bei FMX eigentlich ursprünglich erwartet (vielleicht von kleinen Kinderkrankheiten abgesehen).

[Namenloser]

Wollte ich im letzten Beitrag schon verlinken, hatte aber den Link nicht gefunden: The FMX enumeration anti-pattern. Vermutlich sind es solche Sachen, die Firemonkey so lahm machen.

Falls jemand nur den Anfang liest:

Zitat:

‘Now now’, you might say, ‘no need to play high and mighty over a quick demo from a Developer Relations guy!’ And indeed, if this problem extended no further than a quick demo from a member of Developer Relations I would agree. However, if you browse the FMX source code, you will find this anti-pattern repeated again and again. Ever wondered why large menus in FMX can be so damn slow, even when it is the native menu bar being used? Wonder no more.

[BUG]

Zitat von NamenLozer:

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

Ich habe irgendwie die leise Vermutung ("vektorbasiert"), dass Controls aus mehr als nur ein paar Vertices (~ein Sprite) besteht*. Die heutige Grafikleistung kommt am PC mehr oder weniger nur zum Tragen, wenn das meiste Zeug schon im Speicher der Grafikkarte liegt.

Das für ein flexibles Komponentensystem hinzubekommen stelle ich mir reichlich kompliziert für. Man denke nur an Events wie onPaint.

* Ich habe weder mit FMX gearbeitet, noch in in den Code geguckt => wilde Vermutung

[Der schöne Günther]

Wenn es überhaupt nur annähernd rein an der Grafikkarte liegen würde, wäre es nicht die CPU-Last, die so hoch ist. Mit Direct2D kenne ich mich nicht aus, aber beim Konvertieren und Schieben der Daten auf die Grafikkarte kann man auch nicht allzu viel falsch machen können.

Dinge aus dem Beispiel wie das ungeschickte Wandern durch die Liste werden eher das Problem sein. Bei kleinen Beispielen fällt so etwas performance-mäßig nicht auf, aber im Praxis-Alltag schon.

Dass das genannte Beispiel mit XE3 allerdings ausgemerzt wurde ist doch ein gutes Beispiel, oder? Es kann eigentlich nur besser werden. Die VCL lief an Tag 1 sicherlich auch nicht 100%ig rund...

[stahli]

Da ich das Thema interessant und in Bezug auf FMX auch wichtig finde habe ich mal einige Tests und Überlegungen angestellt.

Video: http://youtu.be/TNpaI2D_nqE
Anlage: Testprojekt (nur Quellen für XE3)

Im Grunde läuft meine Überlegung darauf hinaus, dass nicht ständig alle Controls neu gezeichnet werden müssen sondern zu jedem Control ein Bitmap verwaltet wird, das bei Bedarf neu auf die (das, den?) Canvas kopiert wird. Nur wenn sich das Control selbst ändert (Status, Größe, o.ä.) muss es tatsächlich neu gezeichnet werden. Ansonsten reicht es, das einmal erzeugte Abbild auf das Formular zu kopieren.

So sollten Änderungen auf dem Formular schnell und jederzeit dargestellt werden können und das auch im Debugmodus.
Eine ständige (echte) Neuzeichnung aller über- und untergeordneter Controls könnte vermieden werden.

Die Entscheidung, welche Control-Abbilder neu auf das Formular kopiert werden müssen, könnte das Framework unabhängig von den Zeichenmethoden der Controls entscheiden.

Diese Aktion wäre auch unabhängig vom Mainthread jederzeit möglich (auch im DebugModus).

Ich weiß, dass das etwas ... äh ... unscharf klingt, aber ist das ungefähr verständlich und plausibel?


Man könnte alle Control-Änderungen sofort auf dem Formular sehen.
Es würde eine gewisse Trennung der Control-Zeichenroutinen und der tatsächlichen Formularzeichenfläche geben.

[Namenloser]

Der Fachausdruck in der 3D-Grafikprogrammierung dafür ist übrigens „Impostor“.

Problematisch könnte höchstens der Speicherverbrauch sein, wenn man komplexe, stark verschachtelte Oberflächen hat.

[stahli]

Auf Grund mangelnder Ausbildung muss ich leider selber denken und kann nicht auf Fachbegriffe zurück greifen. (Ich find´s super, dass das bei Dir offenbar so gut läuft. )
Aber dann lag ich wohl nicht ganz so falsch mit meinen Überlegungen.

Letztlich ist der Canvas (oder sagt man die, weil "die Leinwand"?) der Controls auch irgendwo ein abgelegtes Bitmap.

Aber auch einen höheren Speicherverbrauch würde ich nicht überbewerten. Man kann ja einen Ringpuffer nutzen und Bitmaps, die länger nicht mehr gebraucht wurden auch wieder verwerfen (und bei Neubedarf wieder neu erzeugen). Dann müsste man nur alle aktuell sichtbaren Controls als Bitmap-Kopie vorhalten.

Einen Großteil der Probleme mit FMX
- Performance durch Mehrfachzeichnungen
- problematische Formularaktualisierung
- Aktualisierungen losgelöst vom Mainthread (in einem eigenen Thread also)
könnte man damit m.E. lösen.

Dann könnte auch der AniIndikator als ein solcher arbeiten (und nicht als IdleIndikator) und die Formulardarstellung wäre schnell und korrekt möglich.
Wenn ein Control verschoben wird, müsste das nicht ein mehrfaches Neuzeichnen aller möglichen anderer Controls auslösen.

Eine schöne neue Welt würde sich auftun und FMX endlich einen Teil von dem halten, was es verspricht.


Im Grunde wäre dann nur noch ein neues Style-Konzept nötig und der brennende Affe würde schon fast aufrecht gehen.
Das DataBinding klammere ich hier mal aus.

[MEissing]

Zitat von stahli:

Im Grunde läuft meine Überlegung darauf hinaus, dass nicht ständig alle Controls neu gezeichnet werden müssen sondern zu jedem Control ein Bitmap verwaltet wird, das bei Bedarf neu auf die (das, den?) Canvas kopiert wird. Nur wenn sich das Control selbst ändert (Status, Größe, o.ä.) muss es tatsächlich neu gezeichnet werden. Ansonsten reicht es, das einmal erzeugte Abbild auf das Formular zu kopieren.

So macht es zB Xcode/iOS mit seinen UIView/View Controller. Da werden die Bitamps auch gepufftert und schnell wieder reinkopiert.

Auch wir denken über solche Themen nach, um FireMonkey noch besser zu machen.