Frameratenbegrenzung - Versionsgeschichte

Tak2004: /* Siehe auch */

2014-06-07T16:23:31Z

‎Siehe auch

2014-06-07T16:23:15Z

‎Siehe auch

2014-06-07T16:22:57Z

‎Genauigkeit

2014-06-07T16:11:11Z

‎Genauigkeit

2014-06-07T16:05:29Z

2014-06-07T08:39:28Z

‎Die naive Lösung

2014-06-07T08:36:02Z

‎Problemstellung

2013-10-13T14:35:36Z

‎Problemstellung

2013-10-13T14:31:12Z

‎Siehe auch

2013-10-13T14:30:58Z

‎Siehe auch: Framerate

@@ Zeile 67: / Zeile 67: @@
 [[Framecounter]]<br>
 [[Framerate]]<br>
-[[Render_Thread]]
+[[Render_Thread|Render Thread]]
 [[Kategorie:Anleitung]] [[Kategorie:Technik_oder_Algorithmus]]

@@ Zeile 66: / Zeile 66: @@
 ==Siehe auch==
 [[Framecounter]]<br>
-[[Framerate]]
+[[Framerate]]<br>
 [[Kategorie:Anleitung]] [[Kategorie:Technik_oder_Algorithmus]]

@@ Zeile 62: / Zeile 62: @@
 Die beste Lösung ist ein Thread für das render ab zu stellen und vsync für den Renderkontext zu aktivieren.
 [[SwapBuffers]] wird nun bei jedem Aufruf warten, bis der Monitor den nächsten Time-Slice erreicht hat, wechselt Back- und Fron-Buffer, der neue Back-Buffer wird zur Darstellung gebracht und die Funktion kehrt zurück.
-Der Render Thread wird nun M mal die Sekunde durch laufen, wobei M für die aktuelle Monitor Frequenz(aF) steht bzw. darunter, wenn das Rendern länger dauert als 1000ms / aF dauert.
+Der [[Render_Thread|Render Thread]] wird nun M mal die Sekunde durch laufen, wobei M für die aktuelle Monitor Frequenz(aF) steht bzw. darunter, wenn das Rendern länger dauert als 1000ms / aF dauert.
 ==Siehe auch==

@@ Zeile 61: / Zeile 61: @@
 Daher ist es besser sich für Rendering auf vsync zu verlassen.
 Die beste Lösung ist ein Thread für das render ab zu stellen und vsync für den Renderkontext zu aktivieren.
-[[glSwapBuffer]] wird nun bei jedem Aufruf warten, bis der Monitor den nächsten Time-Slice erreicht hat, wechselt Back- und Fron-Buffer, der neue Back-Buffer wird zur Darstellung gebracht und die Funktion kehrt zurück.
+[[SwapBuffers]] wird nun bei jedem Aufruf warten, bis der Monitor den nächsten Time-Slice erreicht hat, wechselt Back- und Fron-Buffer, der neue Back-Buffer wird zur Darstellung gebracht und die Funktion kehrt zurück.
 Der Render Thread wird nun M mal die Sekunde durch laufen, wobei M für die aktuelle Monitor Frequenz(aF) steht bzw. darunter, wenn das Rendern länger dauert als 1000ms / aF dauert.
 Mehr zu Render Threads findet ihr [[Render_Thread|hier]].

@@ Zeile 35: / Zeile 35: @@
 end;
 </source>
 ==Siehe auch==

@@ Zeile 10: / Zeile 10: @@
 ===Die naive Lösung===
-Die einfachste Realisierung der Frameratenbegrenzung ist ein einfaches Hinzufügen der "Sleep" Anweisung in die Hauptschleife. Gehen wir von Sleep(5) aus, so haben wir eine Maximale Framerate von 200FPS. Diese Lösung ist jedoch etwas suboptimal. Gehen wir davon aus, dass das Zeichnen der Inhalte an sich schon 5 Millisekunden dauert, so haben wir nur noch eine Framerate von 100FPS. Auf einem älterem Rechner könnte diese Berechnung auch länger dauern und die erreichte Framerate sich daher noch mehr von unserem anvisierten Wert entfernen.
+Die einfachste Realisierung der Frameratenbegrenzung ist ein einfaches Hinzufügen der "Sleep" Anweisung in die Hauptschleife. Gehen wir von Sleep(5) aus, so haben wir eine Maximale Framerate von 200FPS. Diese Lösung ist jedoch etwas suboptimal. Gehen wir davon aus, dass das Zeichnen der Inhalte an sich schon 5 Millisekunden dauert, so haben wir nur noch eine Framerate von 10FPS. Auf einem älterem Rechner könnte diese Berechnung auch länger dauern und die erreichte Framerate sich daher noch mehr von unserem anvisierten Wert entfernen.
 ===Die intelligente Lösung===

@@ Zeile 1: / Zeile 1: @@
 ==Problemstellung==
-Bei vielen 3D-Anwendungen erfolgt die Bildausgabe so schnell hintereinander, wie die Hardware dies ermöglicht. Das bedeutet aber auch, dass die Auslastung des Computersystems auf 100% ansteigt. Das wiederum benötigt jede Menge Strom. Unser Auge wiederum nimmt eine Bewegung ab ca. 24 Bildern pro Sekunde [[Framerate#24_fps_Mythos|theoretisch]] als flüssig wahr - es bringt also nicht sehr viel, wenn unsere Anwendung mit mehr als 1000 [[FPS]] läuft - wir bekommen davon sowieso nichts mit, außer niedriger Akkulaufzeit und hoher Stromrechnung. Die Lösung für dieses Problem ist eine Frameratenbegrenzung, die die Bildwiederholrate auf einen gewissen Wert limitiert und unsere Anwendung in der Zeit, in der nichts getan werden muss, schlafen legt.
+Bei vielen 3D-Anwendungen erfolgt die Bildausgabe so schnell hintereinander, wie die Hardware dies ermöglicht. Da die CPU die Befehle erzeugen muss, um ein Frame zu rendern, benötigt diese Zeit auf der CPU und so entsteht bei hohen Frameraten entsprechend hohe Auslastung der CPU. Das wiederum benötigt jede Menge Strom. Unser Auge wiederum nimmt eine Bewegung ab ca. 24 Bildern pro Sekunde [[Framerate#24_fps_Mythos|theoretisch]] als flüssig wahr - es bringt also nicht sehr viel, wenn unsere Anwendung mit sehr hohen [[FPS]] läuft - wir bekommen davon sowieso nichts mit, außer niedriger Akkulaufzeit und hoher Stromrechnung.
 ==Ansatz==