Hallo

Ich hab jetzt wieder eine neue Art von Renderung gesehen und frage mich nun was am besten wäre.
Bei den Templates wird beim ApplicationEventsIdle gerendert.
Beim Selektions Tutorial wird mit einem Timer gerendert.
Gibt es noch andere und welche wäre am besten?

Ich hab nämlich das Problem dass wenn ich die Templates benutze dann weiss ich nicht über welche Funktion/Procedure in der Funktion Selection rendern soll.

Was auch noch ganz gerne gemacht wird ist im OnShow eine Endlosschleife die Application.ProcessMessages und die Renderfunktion aufruft.

Wie du renderst ist aber ziemlich egal. Eines haben nämlich alle Methoden gemeinsam. Die Renderfunktion wird kontinuierlich und dauerhaft aufgerufen. Denn die sorgt dafür, dass neuer Inhalt auf den Bildschirm gelangt. Auf mehr kommt es aber auch nicht an. Welche Art für dich die Beste ist ist reine Geschmackssache. Denn das ist das Schöne am Programmieren. Ein Problem und viele Lösungen die sich nur im persönlichen Stil unterschieden.

Ich persönlich bevorzuge OnIdle oder Timer, denn beides sind WindowsEvents und Windows ist nun mal eventbasiert. Was mich bei der Endlosschleife stört, da die eigentlich ein bisschen wider dessen ist was Windows eigentlich aus macht. Nämlich die Events. Aber das ist jedem selbst überlassen.

PS: Ich habe es auch schon erlebt, dass Leute erstaunt waren wenn man ihnen gesagt hat, dass man OpenGL nicht nur in einem Dauerloop benutzen kann. Sondern es auch ganz normal wie OnPaint benutzen kann und nur dann neuzeichnet, wenn sich etwas geändert hat. Je nach Anwendungsfall halt.

Wenn ich es mit Timer machen würde müsste ich nur die Procedure aufrufen
Würde für mich eher einfacher klingen als die Proceduren die im type definiert sind

Da ich sie irgendwie nicht von einer anderen Procedure aus aufrufen kann wie bei der Selektions Funktion

Es ist bestimmt möglich aber hab irgendwie keine Ahnung.
Wäre für mich einfacher eine ganz normale Render Prozedure zu definieren und sie dann aufrufen.

ich nehme bei fester framerate normal nen timer, bei variabler framerate Application.OnIdle.

_________________

Ich benutz in letzer Zeit fast nurnoch das OnPaint ereigniss.. aber das liegt eher daran das die Programme die ich mache keine Spiele etc sind, sondern 2D/3D Tools bei denen es einfach nicht nötig ist das sie dauernd rendern.

Beim Flipbook z.B. wird auch nur dann neu gerendert wenn es benötigt wird.

Ansonsten für spiele etc benutze ich OnIdle, bzw mache ich spiele idR. ohne die VCL = ich nehme einfach die Message-Schleife von Windows.

Aya~

In meinem Framework hab ich die Paint Message angezapft und ein Idle Events selber kreiert, je nach einsatz kann man dann die Renderloop auf OnPaint oder OnIdle pappen. Für Demos OnIdle und für Apps OnPaint.
Zusätzlich nutze ich noch ein Timer, um die FPS auf ein festgelegten Wert zu drosseln und die deltas zwischen Frames sauberer zu errechnen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Die Vor und Nachteile hatte ich damals im Quickstart beschrieben. Hauptsächlicher Nachteil beim OnIdle war die Prozessorbelastung. Die konnte man aber bei Bedarf mit Sleep() wieder drosseln.
Früher haben so ziemlich alle Hier OnIdle genommen. Das scheint wohl aus der Mode gekommen zu sein und OnPaint macht momentan das Rennen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich benutze ja hauptsächlich SDL und daher habe ich meinen eigenen Loop. Ich löse das dabei so, dass ich prüfe, wie lange der letzte Frame her ist. Wenn das weniger ist als sagen wir mal... 10 ms dann wird 5 ms gewartet, bis ein neuer Zeichenversuch gestartet wird. Damit halte ich die Prozessorlast bei 2%, was kein schlechter Wert ist, solange ich es mit dem Rendern nicht übertreibe.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich frage mich des öfteren, wieso leute Probleme haben, dass das Game mit 100% läuft.
Nur bei Notebooks, mit Akku ist das von Nachteil, sonnst ist es sogar von Nachteil, nicht auf voller Last laufen zu lassen.
100% bedeutet ja nicht, dass die anderen Prozesse nicht mehr ran kommen, jeder Prozess bekommt seine minimal benötigte Zeit.
Der rest wird dann dem Loop basierten Prozess zugewiesen. Noch dazu sollte man sagen, wenn dein Prozess nicht das System auslastet, dann tut das der Idle Prozess, da die Desktop CPUs wesentlich länger leben, wenn sie dauerhaft auf volllast laufen.
Noch dazu ist das schlafenlegen ungesund für die Framerate, da sleep ziemlich ungenau und lahm ist(~12ms genau).
usleep(unix alternative) ist da wesentlich genauer. Bei mehrkern CPUs würde der Prozess(ohne Threads) 50% last haben, da er auf dem einen Kern läuft und alles andere vorwiegend auf dem anderen Kern ausgeführt wird(auch hier sorgt das OS für effektivität).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Bei mir passiert es zumindest bei ernsthaften Szene auch eher selten (bis garnicht), dass es zum Sleep aufruf kommt und wenn mehr performance gebraucht wird, wird sie durch das nichtaufrufen vom Sleep ja gewährleistet. So gesehen finde ich meine Methode eigentlich ziehmlich praktisch.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Na ja. Aber mal anders gefragt. Deine Anwendung macht nichts aufwändiges. Deine CPU unterstützt Cool'n'Quite (TM) oder ähnliches und die Anwendung läuft bereits auf 30 oder 60 FPS und verbraucht CPU 3% und GPU 5%. Was für einen Grund sollte es geben die CPU und die GPU restlos auszulasten?

Der Idle Prozess taktet mit passendem Treiber (CnQ) aktuelle CPUs runter bzw versetzt sie tatsächlich in einen schlafenden Zustand. Und ähnliches macht die GPU intern sicherlich auch. Ganz zu schweigen von der Wärme und Geräuschentwicklung und, dass aktuelle TFTs im Schnitt sowieso nur max 60 Hz haben.
Also ich denke ob man so etwas machen will oder nicht hängt vom persönlichen Stil und dem Einsatzgebiet der Anwendung ab. So lange es kein 3D Shooter ist und flüssig läuft bin ich in jedem Fall dafür die FPS zu begrenzen und das obwohl ich nicht mal einen Laptop habe und nicht direkt davon profitieren würde.

Sleep: Ja es ist nicht so genau. Allerdings so eine Abweichung ist mir bisher noch nicht untergekommen. Ich hatte mal getestet wie lange ein sleep(1) bei mir braucht. Und da kamen Zeiten zwischen 0.95 ms und 1.9 ms bei raus.

Die Zahl von sleep ist nicht von mir, sondern von Forenmitgliedern und von MS selber(ist aber auch stark CPU abhängig(treiber,architektur 32/64bit und Model)).
Das Problem, was bei nicht vollast auftritt, ist die ungleichmässige abnutzung von Transistoren, welches zu einem kürzerem leben führt.
Darum gibt es ja einen Idle Prozess, der alle Transistoren nutzt.

Meines Wissens werden auch nicht Teile einer CPU ausgeschalten, wenn sie nicht gebraucht werden, sondern die Frequenz runter gedrosselt(Mobile und anderen CPU Techniken).
Damit ist weniger Leistungaufnahme von nöten(weniger Takte) aber es arbeiten immernoch die ganze CPU mit weniger Power.

Wie ich schon erwähnt habe, hab ich in meinem Framework auch ein Timer drin(je nach compiler Flag low oder high res timer), wo ebenfalls über usleep und sleep die FPS beschränkbar ist aber in meinen Anwendung lasse ich es aus.

Um mal zur Thematik zurück zu kommen, es ist wirklich nur Applikationsabhängig, was man für eine Lösung verwendet.
Bei OnIdle sollte man sehr gut aufpassen, was man tut. In der regel ist es nicht so schlimm, wenn man mehere Funktionsaufrufe zu gunsten der Codeübersicht macht aber in der Loop, die 60-x mal in der Sekunde aufgerufen wird, sollte man zu gunsten der optimierung entscheiden.

Bei OnPaint ist es nicht wild, die wird recht selten aufgerufen, im Vollbild eigentlich garnicht(WM_PAINT(windows event) und Expose(xlib event) kommt nur, wenn in der BoundingBox des eigenen Fensters eine änderung statt fand und der Videospeicher aktualisiert werden muss). Entsprechend Leistungsfreundlich ist die Funktion und für Anwendungen geeignet.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Auch auf die Gefahr hin kleinig oder arschig zu wirken. Aber ich möchte ungern, dass da evtl. ein falscher Eindruck entsteht, der den Ein oder Anderen vielleicht davon abhält eine resourcesparendere Methode zu verwenden.

Meines Wissens nach wird der Assemblerbefehl HLT im Leerlaufprozess ausgeführt. Und "HLT versetzt den Prozessor in den Halte Zustand. Der Prozessor führt erst wieder Befehle aus, wenn dieser durch einen Interrupt oder einen Reset aufgehoben wird." Zitat aus Assmbler gepackt von Joachim Rohde. Denn schließlich ist die CPU ja auch wesentlich kälter. Selbst, wenn der Leerlaufprozess 100% der CPU "beschlägt". Früher hast du aber vollkommen recht. Da wurde dann NOP ausgeführt und da war die CPU wirklich zu 100% ausgelastet.

Nichts desto trotz stimmen die Grundaussagen aber überein. Es gibt keine perfekte ultimative Lösung für alle Fälle. Es kommt immer ganz auf den persönlichen Geschmack (sieht man ja auch gerade hier) und das Einsatzgebiet an.