FMX = Spiele-Engine in schlecht?

[stahli]

Ich war und bin begeistert von der Idee, von der VCL los zu kommen.
FMX verspricht ja viel, bringt aber real viele Probleme mit sich.

Neben mangelhaften Umsetzungen im Detail und dem unausgegorenen Style-Konzept ist die FMX-GUI sehr langsam.

Klar, da muss deutlich mehr berechnet werden als bei der VCL. Es ist auch verständlich, dass beim Umpositionieren von Controls die Umgebung neu (und somit mehrfach) gezeichnet werden muss.
Wenn man aber mal so 3D-Spiele sieht (was absolutes Fremdgebiet für mich ist), dann erkennt man, was wirklich möglich ist.

Kann jemand beide Framework-Konzepte (FMX und SpieleEngines) grundsätzlich vergleichen und Parallelen und Unterschiede erklären?

Könnte man nicht einfach eine SpieleEngine nehmen und statt Monstern und Drachen einfach Schalter und Edits als Figuren/Objekte darstellen?

Wenn im WOW ganze Welten flüssig und Live dargestellt werden können (sogar online), warum ist FMX dann so langsam und störrig?
Sollten sich nicht entsprechend auch Fachanwendungen in der Form von Spielen entwickeln lassen? Könnte man nicht eine Fachanwendung als grafisch anspruchsloses Spiel ansehen?
Gibt es dafür zwingende Gründe?

Die BL-Schicht und Datenverwaltung ist ja ohnehin gleich oder kann gleich sein.
Der Unterschied liegt in der Darstellung und Handling der GUI.

Ein Unterschied ist sicher, dass in Spielen Figuren kaum mit der Maus focusiert werden - oder?
Insofern sind dafür keine oder andere Handles notwendig?


Ich weiß, das ist eine recht naive Fragestellung aber vielleicht kann man sich ja hier mal thematisch ein wenig austoben...

[CHackbart]

Nun das Problem liegt nicht in dem Konzept, sondern in der gnadenlos vermurxten Umsetzung. Ich würde für die Umsetzung eins Spiels auf OpenGL setzen. In den letzten Wochen habe ich mich wieder damit herumgeschlagen, da ich eigentlich in den letzten 10 Jahren nur mit DirectX gearbeitet habe. Opengl ist echt klasse und funktioniert auch mit Firemonkey. Da wir in den letzten Jahren quasi so etwas wie die VCL für D3D umgesetzt haben und das ganze Framework recht abstrakt ist hat mich die Portierung weniger als eine Woche gekostet. Ich habe dabei 2 Varianten entwickelt, die erste war in reinem Firemonkey Code und die zweite Variante reines Opengl. Die CPU Last in ersterem beträgt 40% und bei OpenGl knapp 1%.

[stahli]

Zitat:

Zitat von CHackbart (Beitrag 1216419)

Da wir in den letzten Jahren quasi so etwas wie die VCL für D3D umgesetzt haben und das ganze Framework recht abstrakt ist hat mich die Portierung weniger als eine Woche gekostet. Ich habe dabei 2 Varianten entwickelt, die erste war in reinem Firemonkey Code und die zweite Variante reines Opengl. Die CPU Last in ersterem beträgt 40% und bei OpenGl knapp 1%.

Kann man da mal etwas sehen (DemoExe, Videos, Screenshots, Quelltext)?

[CHackbart]

Quellcode wird schwer, aber ein Video der D3D Version gibt's u.a. hier: http://m.youtube.com/watch?v=LJDhQWDYeRc

Wenn ich am PC bin, kann ich ja mal nen Screenshot bzw. Testbuild hochladen, ansonsten kann man mit der OEM Version von der Software spielen. Die gibt es u.a. Bei Technotrend, Terratec, TBS, Dvbsky. Wer keine DVB Gerät hat, kann zumindest die Videowiedergabe testen :)

[blackfin]

Zitat:

Könnte man nicht einfach eine SpieleEngine nehmen und statt Monstern und Drachen einfach Schalter und Edits als Figuren/Objekte darstellen?

Wenn im WOW ganze Welten flüssig und Live dargestellt werden können (sogar online), warum ist FMX dann so langsam und störrig?
Sollten sich nicht entsprechend auch Fachanwendungen in der Form von Spielen entwickeln lassen? Könnte man nicht eine Fachanwendung als grafisch anspruchsloses Spiel ansehen?

Das kann man sehr wohl. Allerdings ist die Programmierung einer allumfassenden GUI in OpenGL nicht gerade trivial, da man eben jedes Control erstmal mit allen Funktionen selbst bauen muss, auch die Events selbst implementieren muss etc.

An sich hast du jedoch vllkommen recht: Man kann eine Fachanwendung auch als "abgespecktes" Spiel sehen und alles in D3 (OpenGL / Direct3D) bauen.
Früher haben die meisten wohl davon abgesehen, da man dafür eine leistungsfähige Grafikkarte gebraucht hat und Software-Renderer durch die Bank performancetechnisch unbrauchbar waren.
Teilweise trifft das auch heute noch zu, allerdings haben selbst neuere Onboard-Karten inzwischen eine für simple GUI-Darstellung brauchbare OpenGL-Performance.
Der Performance-Gewinn durch OpenGL ist immens, ich habe mal testweise eine Art "Fenster-Manager" mit GLScene geschrieben, der konnte ca. 800 Fenster mit GUI-Controls tiefengestaffelt bei 60fps auf meiner Geforce 7 rendern.
Wobei das eben mit "nur" GLScene war...nativ ist da noch einiges mehr rauszuholen.

Zitat:

Ein Unterschied ist sicher, dass in Spielen Figuren kaum mit der Maus focusiert werden - oder?

Doch klar geht das, entweder über die veraltete GLUT oder eben schneller durch Raycasting etc. Damit kann man jedes Polygon unter der Maus schnell ermitteln.

[Namenloser]

Ich glaube Andorra2D hatte auch rudimentäre GUI-Funktionen...

[cookie22]

Zitat:

Zitat von stahli (Beitrag 1216415)

Ein Unterschied ist sicher, dass in Spielen Figuren kaum mit der Maus focusiert werden - oder?
Insofern sind dafür keine oder andere Handles notwendig?

In Spielen, wie WoW werden die Spielfiguren ständig mit der Maus fokusiert. Das wird im allgemeinen über Hit-Boxen realisiert.

Das Problem an FMX ist einfach die lieblose Umsetzung von Emba. Da wird immer neuer Senf zu gepackt, anstatt erst mal das ganze stabil zum laufen zu bringen. Daran wird sich auch nichts ändern, darum kommt FMX für mich auch nicht in frage.

[Phoenix]

Zitat:

Zitat von stahli (Beitrag 1216415)

Kann jemand beide Framework-Konzepte (FMX und SpieleEngines) grundsätzlich vergleichen und Parallelen und Unterschiede erklären?

Spiele-Frameworks arbeiten grundsätzlich sehr Linear:

* (Teil-)Eingaben verarbeiten und in die interne Datenrepräsentation integrieren
* Diese am UI darstellen (Rendering)
* Wiederholen

Um möglichst hohe Frameraten zu erzielen, passiert Schritt Zwei möglichst häufig, und Schritt Eins wird nicht zwangsläufig immer gemacht. Auch werden bei Schritt 1 oft Teileingaben (und damit unscharfe / unvalidierte) Inputs in Kauf genommen, damit das Spiel möglichst schnell auf (vorhergesehene) Eingaben reagieren kann. Das muss nicht unbedingt passen, aber das das Spiel so schnell ist kann es hinterher nach 3-4 Runden die korrekte Eingabe annehmen und ggf. den Ablauf der letzten drei/vier Frames korrigieren.

Da die Performance der Darstellung sehr stark abhängig von der Hardware des Rechners (sowie den Grafikeinstellungen) und damit sehr individuell ist, wird die Eingabe mit der real abgelaufenen Zeit normalisiert. Sonst hast Du auf modernster Hardware ein unspielbares Frogger (damals wurde das auch noch nicht gemacht).

Konkret heisst das, Spiele haben in aller Regel keine Message-Loop im Sinne von Windows-Anwendungen (wie übrigens iOS auch nicht), sondern laufen kontinuierlich ab.

Zudem konzentrieren sich viele Spiele-Engines darauf, das Rendering möglichst hochperformant hinzubekommen und reduzieren das ganze 3D-Zeug auf Matrizenoperationen, die man dann entsprechend durch den Input antriggert.

Klar lässt sich das eine grundsätzlich irgendwie auf das andere Mappen, aber eine Business-Anwendung hat grundlegend andere Anforderungen als ein Spiel, und dem tragen die unterschiedlichen Frameworks und Herangehensweisen eben (mehr oder weniger) Rechnung.

[Medium]

Jetzt lässt sich natürlich darüber streiten, ob eine Game-Main-Loop einer Messageloop nicht doch irgendwie arg ähnlich ist ;)

MessageLoop: (Pseudo)

Code:

while true do
begin
  PeekMessage();
  case Message of
    WM_FOO: ...
    WM_KEYBDEVENT: VerteileAnAktivesControl;
    WM_PAINT: ZeichneNötigesNeu;
    ...
    WM_CLOSE: Terminate;
   end;
end;

Gameloop: (auch Pseudo)

Code:

while true do
begin
  GetAsyncKeystateUndInterpretiereInputState;
  UpdateSpiellogik;
  Render;
  WennExitStateDannExit;
end;

Bei beiden Systemen verbirgt sich der ganze restliche Rattenschwanz hinter, finde ich, strukturell doch arg ähnlichen Abläufen. Nur werden bei Spielen spätestens ab interner Verarbeitung keine Windows-Messages mehr benutzt, sondern es ist entweder eine Statemaschine ähnlich gebaut, oder man hat ein eigenes, oft THread-Basiertes Signaling-System. Am Ende aber Jacke wie Hose, es ist sicherlich nicht die WinAPI die FMX so bremst :)

PS: Und das Spiele "halbgare" Inputs irgendwie anders handhaben wäre mir auch unbekannt. Das trifft eher auf Netzverkehr zu, wo ein Client Vorhersagen über die eventuelle Bewegung anderer Spieleravatare trifft, und nach einem Updatesyklus vom gemeinsamen Server notfalls nachsynchronisiert. Gerade bei FPS Spielen ist eine ultra schnelle und korrekte Eingabeverarbeitung doch das A und O.

[blackfin]

Zitat:

...aber eine Business-Anwendung hat grundlegend andere Anforderungen als ein Spiel...

Was das Data Modelling angeht ganz sicher, aber es geht hier ja hauptsächlich um die Darstellung von GUI-Controls.
Es schliesst sich ja nicht aus, das Data Modelling mit einem "Business-Framework" zu gestalten, für die GUI jedoch dann 3D Technik zu verwenden.
Auf kurz oder lang wird das denke ich sogar der Standard werden. GUIs für Desktopanwendungen verschieben sich sowieso immer mehr in die Richtung "HTML-Technik", der nächste Schritt wird dann denke ich etwas in der Art wie WebGL-Technik für GUI-Darstellungen sein. (nur meine bescheidene Meinung).
Wenn ich mir sowas wie "Node-Webkit" ansehe, gehen mir echt die Augen auf. Und das ist erst der Anfang.

[Der schöne Günther]

Zitat:

Zitat von stahli (Beitrag 1216415)

Kann jemand beide Framework-Konzepte (FMX und SpieleEngines) grundsätzlich vergleichen und Parallelen und Unterschiede erklären?

Ich persönlich kenne leider nur das eine, nicht das andere (FireMonkey) :-D

Deshalb weiß ich nichts von Designschwächen, wundere mich aber, was bei der Performance das Problem sein sollte? Wenn FM im Grunde doch auch auf schwachen Mobilgeräten laufen soll? Gibt es auf FireMonkey-Oberflächen bestimmte Dinge welche besonders stark Performance fressen?

Echtzeit 3D-Visualisierungen (und da gibt es neben Spielen eine Menge Anwendungsgebiete wie CAD, VR und Datenvisualisierungen) beziehen ihre Grafikqualität in der Regel von der Rohleistung des Grafikchips: Hier sind es in der Regel diskrete Drahtgittermodelle auf die Bitmaps geklebt werden. Weiterhin extrem parallelisierbare "Shader"-Programme die sich um die Schattierung, Animation und andere "Effekte" des Bildes kümmern. Letztendlich die Übertragung auf ein (oder mehr) zweidimensionale Pixelbilder mit ganzzahligen Koordinaten. Soviel nur zur Rendering-Pipeline, von anderen Gebieten wie Physik, KI oder Scheduling für das Nachladen von Inhalten zur Laufzeit ganz zu schweigen :)

Für eine normale 2D-GUI fallen Dinge ausgefallene Shader-Effekte und hochauflösende Drahtgittermodelle direkt flach, im Endeffekt haben wir hier für das Rendern viel weniger Arbeit. Für das Rendern. Eine allgemeingültige, funktionierende, auf mehreren Betriebssystemen funktionierende GUI muss natürlich um einiges mehr können, als eine Handvoll vorgefertigte Grafikelemente auf dem Bildschirm anzeigen und eventuell merken, wenn jemand eine Taste drückt oder einen Mauszeiger darüber schiebt.

Ist die Rendering-Performance wirklich schlecht? Auf allen Systemen?

Zitat:

Zitat von CHackbart (Beitrag 1216419)

Ich habe dabei 2 Varianten entwickelt, die erste war in reinem Firemonkey Code und die zweite Variante reines Opengl. Die CPU Last in ersterem beträgt 40% und bei OpenGl knapp 1%.

Gerade das zeigt doch dann, dass es nicht das pure Rendering an sich ist, sondern irgendwo anders Performance verballert wird, oder?
Ich weiß noch nichts von FireMonkey, aber irgendwo anders wird man sich einen Flaschenhals gebaut haben...


Ich bin trotzdem gespannt und hoffe irgendwann einmal die Zeit zu haben, FireMonkey auszuprobieren. Das einzige was ich von FM weiß ist dass es angeblich voll vektorbasiert ist und angeblich auf allen Plattformen wunderbar läuft :stupid:

[CHackbart]

Zitat:

Gerade das zeigt doch dann, dass es nicht das pure Rendering an sich ist, sondern irgendwo anders Performance verballert wird, oder?

Da hast du Recht es sind mehrere Ursachen die alle zusammen zu einer schlechten Performance führen. Ich denke mal der Hauptaugenmerk bei den meisten Delphi Anwendungen liegt in der Entwicklung von Datenbankanwendungen und auch wenn man sagt es sollten keine Tabellen mit mehreren hundert Einträgen verwendet werden, mit der Begründung das dies eh kein Mensch liest, so sollte doch zumindest die Tabelle in der Lage sein diese Daten darzustellen. Das gleiche gilt für TListview und TTreeview Komponenten. Vor ein paar Tagen gab es mal einen Post hier im Forum bezüglich TTreeview. Zumindest in XE2 wurde jede Expand-Änderung eines Eintrags an jedes darunter liegende Node rekursiv übergeben und diese wurden ALLE neu gezeichnet. Im ungünstigsten Fall hast du dort mehrere hundert Elemente die dann einfach neu gerendert werden. Selbst wenn jemand so einen derartigen Code im Blindflug und unter massiven Zeitdruck erstellt, das machen wir ja alle ab und zu, dann sollte man doch im Betatest darauf aufmerksam werden. Ich denke mal Listen und Baumansichten gehören definitiv zu Kernkomponenten die auch bis zum Exzess getestet werden sollten.
Außerdem bauen ja alle 2D-Elemente auf die Canvasklassen auf die zumindest in XE2 (wie gesagt ich kann nur über XE2 reden, da ich XE4 nur als Demoversion testen wollte und *erm* naja in der Testzeit nach der Installation nur einmal kurz damit "gespielt" habe) extrem unperformant sind. Prinzipiell kann man eine TCanvasklasse bauen die z.B. komplett OpenGL nutzt. Das würde zumindest einen Großteil der Geschwindigkeitsprobleme beheben.

Christian

[Der schöne Günther]

Zitat:

Zitat von CHackbart (Beitrag 1216662)

so sollte doch zumindest die Tabelle in der Lage sein diese Daten darzustellen. Das gleiche gilt für TListview und TTreeview Komponenten. Vor ein paar Tagen gab es mal einen Post hier im Forum bezüglich TTreeview. Zumindest in XE2 wurde jede Expand-Änderung eines Eintrags an jedes darunter liegende Node iteratiov übergeben und diese wurden ALLE neu gezeichnet

Ja, ich glaube, ich sehe wohin die Reise geht.

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

Zitat von stahli (Beitrag 1216699)

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:

Zitat von NamenLozer (Beitrag 1216893)

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. :mrgreen: (Ich find´s super, dass das bei Dir offenbar so gut läuft. :thumb:)
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.

[Namenloser]

Zitat:

Zitat von stahli (Beitrag 1226831)

Auf Grund mangelnder Ausbildung muss ich leider selber denken und kann nicht auf Fachbegriffe zurück greifen. :mrgreen: (Ich find´s super, dass das bei Dir offenbar so gut läuft. :thumb:)

:oops:
Nee, das kenne ich auch einfach nur aus dem Internet ;)

[stahli]

[OT]Aber Du hast es wenigstens gefunden :-) Studium läuft?[/OT]

[MEissing]

Zitat:

Zitat von stahli (Beitrag 1226773)

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.

[stahli]

Noch besser wäre super! :)

Zitat:

Zitat von meinen Überlegungen gestern Nachmittag auf dem NachHauseWeg

Wenn ich mit meinem Fahrrad vor einem Haus lang fahre wird ja auch nicht die Hauswand hinter mir nach jedem cm neu gestrichen. ;-)

Im Ernst, das würde mich (wenn das Resultat das hält, was ich mir davon verspreche) schon mal ziemlich mit Emba und FMX versöhnen.
Wenn es schnell ginge und als BugFix nicht zu teuer wäre um so besser.

Vielleicht kommt FMX damit ja doch noch auf die Füße.

Gibt es eigentlich bekannte richtige ausgewachsene und komplexe FMX-Anwendungen für Win oder Mac? Bisher kann ich mir das kaum vorstellen.

[greenmile]

Ich hätte da eine Anwendung. Link dann gerne per PM.

Da wir jetzt Android, iOS und iMac haben gehe ich mal davon aus (besser gesagt hoffe ich), dass es jetzt an Windows 8 Tablets und/oder Linux geht. Damit hätten wir dann alle interessanten Plattformen, dann wird sicherlich (hoffentlich) an der Performance geschraubt. Mit Delphi XE 8 :)

Die Performance ist Grotte. Aber irgendwie kann ich das auch im Ansatz nachvollziehen. Ich meine, wir entwickeln mit einer Oberfläche App's für 4 Plattformen und auf allen läuft es größtenteils. Irgendwie Knaller finde ich. Ich gehe jetzt einen anderen Weg: Die Anwendung an sich (also die Mainform) mit Firemonkey und die Performance-Teile oder die, die von FMX nicht abgedeckt werden, dann halt mit externen Tools (wie mit meiner neuen Liebe, der TMS mCL oder iCL). Hat den angenehmen Nebeneffekt, dass die Buttons auch wirklich wie echte Mac Buttons aussehen; sind halt echte ;)

[mkinzler]

Dann bräuchte man nur noch einen Crossplattform Wrapper um die nativen Controls.

[Union]

Ja, eine XCL wäre gut. Firemonkey entspricht wirklich dem Thread-Titel.

[stahli]

Ich will mich nochmal auf Beitrag #20 beziehen...

Ich zeichne dort unter FMX und Win8 einfach Rechtecke auf einen Formularcanvas.
Wenn das Projekt unter Win7 läuft wird aber nichts gezeichnet und die entsprechende Funktion ist ruck zuck fertig.

Anbei mal das entsprechende Projekt (incl. Exe).
Button1 sollte ein grünes Rechteck wie im Bild füllen.
Button2 zählt ein paar Sekunden eine Variable hoch.
Am Ende gib es jeweils einen Beep.

Mich interessiert, unter welchen Systemen
- wird das grüne Rechteck gezeichnet und bleibt es nach Abschluss sichtbar?
- wenn nicht, dauert Button1 trotzdem 2-3 Sek (bis zum Beep)?
- läuft der AniIndikator während Button1 + 2 weiter?

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:

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