Programm verbraucht zuviel Prozessorleistung - Wie kann ich Lag verhindern?

[Uwe Raabe]

Zitat von Neumann:

Bei einem Timer kann noch passieren dass ein Event noch nicht abgearbeitet ist wenn der nächste kommt

Das kann aber nur passieren, wenn innerhalb des Event-Handlers sowas wie Application.ProcessMessages aufgerufen wird, was ich auf jeden Fall vermeiden würde! Andernfalls sind die Timer-Events durch die Message-Queue schon serialisiert und die gezeigte Blockung ist überflüssig. Natürlich kann nach dem Durchlaufen des Event-Handlers schon die nächste Timer-Message vorliegen, aber dann ist eben das System wirklich zu langsam. Dann würde das von Sherlock vorgeschlagene abschalten die Sache etwas entzerren. Andererseits würde ich dann wohl einen ganz anderen Ansatz wählen.

[Sir Rufo]

Du musst immer die Zeit berechnen, die zwischen dem letzten Aufruf und dem aktuellen Aufruf vergangen ist und dann berechnen, wie viele Schritte eigentlich hätten erfolgen sollen.
Die noch verbleibende Zeit speicherst du als Reserve und wird beim nächsten Schritt berücksichtigt.

Diese Schritte werden dann ausgeführt und dann wird das Zeichnen einmalig veranlasst.

Hier mal eine Klasse, die dieses berücksichtigt

Delphi-Quellcode:

unit Animator;

interface

  uses
    Classes,
    SysUtils,
    ExtCtrls;

  type
    TAnimator = class( TComponent )
    private
      FLocked     : Boolean;
      FTimer      : TTimer;
      FAccu       : Integer;
      FLastCall   : TDateTime;
      FOnStep     : TNotifyEvent;
      FOnPaint    : TNotifyEvent;
      FResolution : Cardinal;
      procedure TimerEvent( Sender : TObject );
      procedure SetResolution( const Value : Cardinal );
      function CalculateSteps : Integer;
      function GetEnabled : Boolean;
      procedure SetEnabled( const Value : Boolean );
      procedure DoStep;
      procedure DoPaint;
    public
      constructor Create( AOwner : TComponent ); override;
      destructor Destroy; override;

      // Event für den Berechnungs-Schritt
      property OnStep : TNotifyEvent read FOnStep write FOnStep;
      // Event für die Zeichen-Schritt
      property OnPaint : TNotifyEvent read FOnPaint write FOnPaint;
      // Auflösung in Millisekunden
      property Resolution : Cardinal read FResolution write SetResolution default 30;
      property Enabled : Boolean read GetEnabled write SetEnabled default True;
    end;

implementation

  uses
    DateUtils;

  { TAnimator }

  function TAnimator.CalculateSteps : Integer;
    var
      LNow  : TDateTime;
      LSpan : Integer;
    begin
      LNow := Now;

      // Zeitspanne zwischen letzem Aufruf und Jetzt
      // plus dem noch nicht berücksichtigtem Zeitvorrat
      LSpan := MilliSecondsBetween( LNow, FLastCall ) + FAccu;
      // Anzahl der Schritt pro Zeitauflösung
      Result := LSpan div FResolution;
      // Restzeit in den Zeitvorrat
      FAccu := LSpan - Result * FResolution;

      FLastCall := LNow;
    end;

  constructor TAnimator.Create( AOwner : TComponent );
    begin
      inherited;
      FLastCall       := Now;
      FResolution     := 30;
      FTimer          := TTimer.Create( Self );
      FTimer.OnTimer  := TimerEvent;
      FTimer.Interval := 1;
      FTimer.Enabled  := True;
    end;

  destructor TAnimator.Destroy;
    begin

      inherited;
    end;

  procedure TAnimator.DoPaint;
    begin
      if Assigned( OnPaint )
      then
        OnPaint( Self );
    end;

  procedure TAnimator.DoStep;
    begin
      if Assigned( OnStep )
      then
        OnStep( Self );
    end;

  function TAnimator.GetEnabled : Boolean;
    begin
      Result := FTimer.Enabled;
    end;

  procedure TAnimator.SetEnabled( const Value : Boolean );
    begin
      if Value = Enabled
      then
        Exit;

      if Value
      then
      begin

        // Wird der Timer wieder eingeschaltet, dann
        // LastCall und Accu wieder zurücksetzen

        FLastCall := Now;
        FAccu     := 0;
      end;

      FTimer.Enabled := Value;
    end;

  procedure TAnimator.SetResolution( const Value : Cardinal );
    begin
      if ( Value = FResolution ) or ( Value = 0 )
      then
        Exit;

      FResolution := Value;
    end;

  procedure TAnimator.TimerEvent( Sender : TObject );
    var
      LSteps : Integer;
    begin
      if FLocked
      then
        Exit;

      FLocked := True;
      try

        LSteps := CalculateSteps;

        if LSteps = 0
        then
          Exit;

        while ( LSteps > 0 ) do
        begin
          DoStep;
          Dec( LSteps );
        end;

        DoPaint;

      finally
        FLocked := False;
      end;
    end;

end.

Und ein kleines Testprogramm, was drei Shapes unterschiedlich schnell über die Form fliegen lässt

Delphi-Quellcode:

unit ViewMain;

interface

  uses
    Animator,
    Windows,
    Messages,
    SysUtils,
    Variants,
    Classes,
    Graphics,
    Controls,
    Forms,
    Dialogs,
    ExtCtrls;

  type
    TFloatPoint = record
      x, y : Extended;
    end;

    TMainView = class( TForm )
      Shape1 : TShape;
      Shape2 : TShape;
      Shape3 : TShape;
      procedure FormCreate( Sender : TObject );
    private
      FShape1Pos : TFloatPoint;
      FShape2Pos : TFloatPoint;
      FShape3Pos : TFloatPoint;
      FAnimator  : TAnimator;
      procedure AnimatorStep( Sender : TObject );
      procedure AnimatorPaint( Sender : TObject );
    public

    end;

  var
    MainView : TMainView;

implementation

{$R *.dfm}

  procedure TMainView.AnimatorPaint( Sender : TObject );
    begin
      // Hier wird das Zeichnen der Oberfläche veranlasst

      Shape1.Top  := Round( FShape1Pos.y );
      Shape1.Left := Round( FShape1Pos.x );

      Shape2.Top  := Round( FShape2Pos.y );
      Shape2.Left := Round( FShape2Pos.x );

      Shape3.Top  := Round( FShape3Pos.y );
      Shape3.Left := Round( FShape3Pos.x );
    end;

  procedure TMainView.AnimatorStep( Sender : TObject );
    begin
      // Hier erfolgen NUR die Berechnungen

      // Shape1

      // Geschwindigkeit 500 Pixel/Sekunde
      FShape1Pos.y := FShape1Pos.y - ( 500 / 1000 * FAnimator.Resolution );

      // Wenn es nach oben rausrutscht, dann von unten wieder komplett reinkommen lassen
      if FShape1Pos.y < 0
      then
        FShape1Pos.y := FShape1Pos.y + Self.Height - Shape1.Height;

      // Shape2

      // Geschwindigkeit 200 Pixel/Sekunde
      FShape2Pos.y := FShape2Pos.y - ( 200 / 1000 * FAnimator.Resolution );

      // Wenn es nach oben rausrutscht, dann von unten wieder komplett reinkommen lassen
      if FShape2Pos.y < 0
      then
        FShape2Pos.y := FShape2Pos.y + Self.Height - Shape2.Height;

      // Shape3

      // Geschwindigkeit 800 Pixel/Sekunde
      FShape3Pos.y := FShape3Pos.y - ( 800 / 1000 * FAnimator.Resolution );

      // Wenn es nach oben rausrutscht, dann von unten wieder komplett reinkommen lassen
      if FShape3Pos.y < 0
      then
        FShape3Pos.y := FShape3Pos.y + Self.Height - Shape3.Height;

    end;

  procedure TMainView.FormCreate( Sender : TObject );
    begin

      // Positionen der Objekte merken

      FShape1Pos.x := Shape1.Left;
      FShape1Pos.y := Shape1.Top;

      FShape2Pos.x := Shape2.Left;
      FShape2Pos.y := Shape2.Top;

      FShape3Pos.x := Shape3.Left;
      FShape3Pos.y := Shape3.Top;

      // Animator initialisieren

      FAnimator         := TAnimator.Create( Self );
      FAnimator.OnStep  := AnimatorStep;
      FAnimator.OnPaint := AnimatorPaint;
    end;

end.

[Popov]

Eine Alternative wäre - du richtest dich nicht nach Timer, sondern nach möglichen Fps.

Beispiel: du hast einen Ball der auf einem 1024 waagerechtem Bildschirm von links nach rechts bewegt werden soll.

- Möglichkeit 1: du bewegst den Ball jeweils um einen Pixel nach rechts. Damit das alles innerhalb einer Sekunde angezeigt wird, müssten 1024 Bilder pro Sekunde aufgebaut werden. Wird wohl nicht klappen, wenn höchstens 100. also wird der Ball 10 Sekunden brauchen. Das Spiel ist flüssig, wirkt aber zu langsam.

- Möglichkeit 2: du analysierst wie viel Bilder pro Sekunde gerade möglich sind, z. B. 30. Somit wird der Ball nicht um 1 Pixel pro Frame bewegt, sondern 1024 / 30 = 35 Pixel. Der Ball passiert den Bildschirm innerhalb einer Sekunde. Wenn FPS zu gering wird, hackt das Spiel, bleibt aber in der Zeit.

[Sir Rufo]

@Popov

Genau so macht man das eben nicht.

Man ermittelt, wieviele Zeiteinheits-Schritte man aktuell abarbeiten muss und arbeitet diese ab.
Dann klatscht man das Ergebnis auf den Bildschirm (das dauert idR am längsten).

Wie oft man das auf den Bildschirm bekommt, das ist dann die FPS (und die ist abhängig von der Komplexität der Animation sowie der aktuell verfügbaren Rechenleistung).

Andersherum fällt man nur über die eigenen Füße (erst FPS berechnen und abhängig davon die Berechnung der Positionen).

[hathor]

Kleiner Tipp:

Wenn es "nur" auf LCD mit 60Hz Bildfrequenz laufen soll, dann macht es keinen Sinn, mehr als 60 Änderungen im Bild zu erzeugen.
Es wird nicht angezeigt!
Beispiel:
Es soll sich etwas vom linken zum rechten Bildrand bewegen bei 1920 horizontale Pixel und einer Geschwindigkeit von 1920 Pixel/sec, dann muss man nur 1920/60=32 Positionen berechnen und nicht 1920!
Bei 120Hz Bildfrequenz sind es entsprechend 64 Positionen. Der Rest ist Luxus.

[Astobix]

Schonmal vielen Dank für die Tipps/Hilfe! Ich probiere das dann mal aus.

Einige Fragen sind mir aber noch geblieben:

1. Die Frage mit dem Doublebuffering. Sobald ich es auf true setzte, verdoppelt sich fast die benötigte ProzessorLeistung. Wenn ich es auf false belasse, flimmert alles. Gibt es Alternativen, die weniger Ressourcen kosten, aber trotzdem das Flimmern verhindern?

2. Ich habe mich noch nicht wirklich mit Threads auseinandergesetzt, würde es irgendeinen Vorteil bringen, das Programm in mehrere Threads aufzuteilen? Kann man damit das Programm auf mehrere Kerne aufteilen - und ist das sinnvoll?

[Sir Rufo]

1. Logisch, denn jede Veränderung veranlasst das System den Bildschirm neu zu zeichnen. Beim DoubleBuffer sogar jeweils doppelt.
   Benutze keine Komponenten, sondern zeichne alles selber auf ein Bitmap. Wenn du mit dem Bitmap fertig bist, dann zeichne dieses Bitmap auf die Form -> Das System muss jetzt nur einmal neu zeichnen.
2. Die Threads werden dir bislang noch nicht weiterhelfen, denn der größte Aufriss ist das Zeichnen auf dem Bildschirm und der darf eh nur synchronisiert im Hauptthread erfolgen.

[Sir Rufo]

Ich habe da mal den Animator noch etwas angepasst, und der ermittelt jetzt auch noch FPS (mit einer Glättung).

Auf der Form ist jetzt noch eine Checkbox zum Ein-/Ausschalten des Animators und ein SpinEdit zum Anpassen der Resolution (Zeiteinheit in Millisekunden).

Durch das Erhöhen dieser Zeiteinheit sieht man, dass das Ergebnis mehr ruckelt und je kleiner, umso flüssiger wird es.

Man sieht aber auch, dass das System nicht aus dem Tritt kommt und die Shapes immer passend ihre Bahnen ziehen und beim Zeichnen sind die da, wo man es auch zu dem Zeitpunkt vermuten würde.

Anhang mit Sourcen und kompilierter EXE

[Popov]

Zitat von Sir Rufo:

@Popov

Genau so macht man das eben nicht.

Das will ich dir glauben, aber sieh mal - ich habe einen einfachen Rechner und gelegentlich installiere ich einen 3D Egoshooter, der für meinen Rechner einfach zu neu ist. Ergebnis, ich bekomme in einer Sekunde mal ein Frame zu sehen. Nun könnte man meinen, dass der edle Krieger für die 100 Meter deshalb 100 Sekunden braucht, denn wenn nichts angepasst wird, dann müssen alle Frames abgespielt werden.

Passiert eben nicht. Was ich sehe ist ein Frame pro Sekunde und den edlen Krieger in 10 Meter Abständen (vorausgesetzt er läuft die 10 Meter in einer Sekunde).

Das Spiel läuft also in Realtime ab. Und nichts anderes habe ich geschrieben. Entweder läuft das Spiel in Zeitlupe ab oder es hackt, weil es in Realtime abläuft. Vielleicht habe ich das falsch ausgedrückt, hab aber das richtige gemeint. Das Problem ist nur, dass man nicht überall immer eine Welt Engine hat, so dass man sich nach Abstand richten kann.

[Sir Rufo]

Zitat von Popov:

Zitat von Sir Rufo:

@Popov

Genau so macht man das eben nicht.

Das will ich dir glauben, aber sieh mal - ich habe einen einfachen Rechner und gelegentlich installiere ich einen 3D Egoshooter, der für meinen Rechner einfach zu neu ist. Ergebnis, ich bekomme in einer Sekunde mal ein Frame zu sehen. Nun könnte man meinen, dass der edle Krieger für die 100 Meter deshalb 100 Sekunden braucht, denn wenn nichts angepasst wird, dann müssen alle Frames abgespielt werden.

Passiert eben nicht. Was ich sehe ist ein Frame pro Sekunde und den edlen Krieger in 10 Meter Abständen (vorausgesetzt er läuft die 10 Meter in einer Sekunde).

Das Spiel läuft also in Realtime ab. Und nichts anderes habe ich geschrieben. Entweder läuft das Spiel in Zeitlupe ab oder es hackt, weil es in Realtime abläuft. Vielleicht habe ich das falsch ausgedrückt, hab aber das richtige gemeint. Das Problem ist nur, dass man nicht überall immer eine Welt Engine hat, so dass man sich nach Abstand richten kann.

Ja du hast wohl das richtige gemeint, allerdings ist die FPS die Resultierende daraus und nicht das, was man zur Berechnung nimmt