Einzelnen Beitrag anzeigen

Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#54

AW: FMX = Spiele-Engine in schlecht?

  Alt 18. Jan 2014, 10:47
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 MSDN-Library durchsuchenPeekMessage, MSDN-Library durchsuchenTranslateMessage, MSDN-Library durchsuchenDispatchMessage).

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.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat