So berechnen Sie die Bildrate FPS von Webanimationen

Standards für flüssige Animation

Lassen Sie uns zunächst einige Konzepte klären. FPS bedeutet die Anzahl der Bildschirmaktualisierungen pro Sekunde. Die kontinuierlichen Bilder, die wir normalerweise sehen, bestehen aus einer Reihe von Standbildern. Jedes Bild wird als Frame bezeichnet. FPS ist eine physikalische Größe, die die Geschwindigkeit beschreibt, mit der sich der „Frame“ ändert.

Theoretisch gilt: Je höher die FPS, desto flüssiger ist die Animation. Derzeit beträgt die Bildschirmaktualisierungsrate der meisten Geräte 60 Mal pro Sekunde. Generell gilt also, dass der Animationseffekt am besten ist, wenn die FPS 60 Bilder/s beträgt, was bedeutet, dass jedes Bild 16,67 ms dauert.

Freunde, die häufig FPS-Spiele spielen, müssen natürlich wissen, dass für FPS-Spiele wie PUBG/CSGO die Verwendung eines Monitors mit einer Bildwiederholfrequenz von 144 Hz empfohlen wird. Ein 144-Hz-Monitor bezieht sich speziell auf einen Monitor mit einer Bildwiederholfrequenz von 144 Hz pro Sekunde. Im Vergleich zur Bildwiederholrate von 60 Sekunden gewöhnlicher Monitore ist die Bilddarstellung flüssiger. Daher eignen sich 144-Hz-Monitore besser für Ego-Shooter-Spiele, bei denen der Betrachtungswinkel häufig hohe Bewegungsgeschwindigkeiten aufweist.

Dies ist jedoch nur eine Funktion mit hoher Bildwiederholrate, die vom Display bereitgestellt wird. Ob sie für unsere Webanimation unterstützt wird, hängt vom Browser ab, und die Bildwiederholrate der meisten Browser beträgt 60 Mal pro Sekunde.

Intuitives Gefühl, Erfahrung mit unterschiedlichen Bildraten:

• Animationen mit einer Bildrate von 50 bis 60 FPS laufen recht flüssig und angenehm ab;
• Bei Animationen mit einer Bildrate zwischen 30 und 50 FPS variiert der Komfort aufgrund unterschiedlicher Empfindlichkeitsstufen von Person zu Person.
• Bei Animationen mit einer Bildrate unter 30 FPS treten deutliche Verzögerungen und Unbehagen auf.
• Auch bei Animationen mit großen Schwankungen der Bildfrequenz kommt es zu spürbaren Verzögerungen.

OK, wie erhalten wir also den aktuellen FPS-Wert unserer Seitenanimation genau?

Methode 1: Verwenden Sie Chrome Developer Tools

Chrome bietet leistungsstarke Funktionen für Entwickler. In den Entwicklertools können wir die Option FPS-Messgerät wie folgt auswählen:

Über diese Schaltfläche können Sie die Echtzeitüberwachung der Bildrate und der GPU-Nutzung der Seite aktivieren.

Mangel:

• Dies kann nur eine oder mehrere Seiten gleichzeitig beobachten und erfordert eine manuelle Echtzeitbeobachtung
• Daten können nur subjektiv sein und es gibt keine sehr genauen Daten, die ständig gemeldet oder gesammelt werden.

Deshalb brauchen wir einen intelligenteren Ansatz.

Methode 2: Verwenden der Frame Timing API

Bevor wir die folgende Methode vorstellen, wollen wir noch einige grundlegende Kenntnisse vermitteln.

Frühe Architektur des Blink-Kernels

Nehmen Sie als Beispiel die Blink-Rendering-Seite des Chrome-Browserkernels. Bei früheren Chrome-Browsern entspricht jede Seitenregisterkarte einem unabhängigen Rendererprozess, der den Hauptthread und den Synthesethread umfasst. Frühe Chrome-Kernelarchitektur:

Unter diesen ist der Hauptthread hauptsächlich verantwortlich für:

• Javascript-Berechnung und -Ausführung
• CSS-Stilberechnung
• Layoutberechnung
• Zeichnen Sie Seitenelemente in Bitmaps (Malen), das heißt Rasterung (Raster)
• Übergeben Sie das Bitmap an den Compositing-Thread

Der Kompositionsthread ist hauptsächlich verantwortlich für:

• Laden Sie die Bitmap (GraphicsLayer-Ebene) als Textur auf die GPU hoch
• Berechnen Sie den sichtbaren und bald sichtbaren Teil der Seite (Scrollen).
• CSS-Animation
• Weist die GPU an, die Bitmap auf dem Bildschirm zu zeichnen

OK, Nebel, was ist das? Nachdem Sie diese beiden Themen kennengelernt haben, besteht das nächste Konzept darin, die subtilen Unterschiede zwischen CSS-Animation und JS-Animation zu klären (natürlich sind beides Webanimationen).

Die subtilen Unterschiede zwischen JS-Animation und CSS-Animation

Bei JS-Animationen entspricht die Framerate der Zeit, die der Haupt-Thread und der Synthese-Thread zusammen benötigen. Für flüssige Animationen soll jedes Frame weniger als 16,67 ms dauern.

Was die CSS-Animation betrifft, so wird ihr Prozess nicht vom Hauptthread beeinflusst, sodass die vom Synthesethread verbrauchte Zeit erhalten werden soll. Die Zeichenfrequenz des Synthesethreads spiegelt auch den Prozess des Scrollens und der CSS-Animation wider.

Die wichtigste Schlussfolgerung aus dem oben Gesagten ist: Wenn wir wissen, wie lange jedes Frame des Haupt-Threads und des Synthese-Threads dauert, können wir ungefähr die Framerate der entsprechenden Web-Animation ermitteln. Kann uns die oben erwähnte Frame Timing API dabei helfen, diesen Zeitpunkt zu ermitteln?

Was ist die Frame-Timing-API?

Die Frame Timing API ist Mitglied des Web Performance Timing API-Standards.

Web Performance Timing API ist eine Reihe von Leistungs-API-Standards, die vom W3C eingeführt wurden, um Entwicklern dabei zu helfen, die Leistung verschiedener Aspekte einer Website genau zu analysieren und zu steuern und die Leistung einer Website zu verbessern.

Es enthält viele Unterklassen-APIs zum Ausführen verschiedener Funktionen, wie folgt (Auszug aus der Verwendung der Leistungs-API zur schnellen Analyse der Leistung des Web-Front-Ends, Sie können natürlich auch die englische Originaleinführung lesen: Web Performance Timing API):

Wie benutzt man es? Am Beispiel von Navigation Timing, Performance Timeline und Resource Timing werden sie für kompatible Browser als schreibgeschützte Eigenschaften angezeigt, die auf window.performance gemountet sind.

Drucken Sie window.performance in der Debugger-Konsole aus und überprüfen Sie die Timing-Eigenschaft:

Was stellen die Variablenreihen in diesem Objekt dar? Sie repräsentieren jeden wichtigen Zeitpunkt im gesamten Ladevorgang unserer Seite. Sie können sich dieses Bild genauer ansehen:

Anhand dieses Bilds und des obigen window.performance.timing können wir ganz einfach die von jedem wichtigen Knoten der Seite verbrauchte Zeit berechnen. Dies ist die Stärke der Web Performance Timing API. Wenn Sie interessiert sind, können Sie sie im Detail studieren und in Seitenstatistiken verwenden.

Übersicht über die Frame-Timing-API

Okay, kommen wir endlich zum Thema zurück. Mithilfe der Frame Timing API in der Web Performance Timing API können wir ganz einfach die Zeit des Hauptthreads und des Synthesethreads in jedem Frame ermitteln. Oder es ist einfacher, direkt die für jedes Bild benötigte Zeit zu ermitteln.

Holen Sie sich die Datensätze des Render-Hauptthreads und des Synthesethreads. Die in jedem Datensatz enthaltenen Informationen sind im Wesentlichen wie folgt, wie im Code gezeigt (siehe Entwicklerfeedback erforderlich: Frame Timing API):

var rendererEvents = window.performance.getEntriesByType("renderer");
var compositeThreadEvents = window.performance.getEntriesByType("composite");

Oder:

var Beobachter = neuer PerformanceObserver(Funktion(Liste) {
    var perfEntries = list.getEntries();
    für (var i = 0; i < perfEntries.length; i++) {
        console.log("frame: ", perfEntries[i]);
    }
});
 
// Frame Timing abonnieren
Beobachter.beobachten({entryTypes: ['frame']});

Jeder Datensatz enthält die folgenden grundlegenden Informationen:

{
  Quellbildnummer: 120,
  Startzeit: 1342.549374253
  CPU-Zeit: 6,454313323
}

Jeder Datensatz enthält eine eindeutige Frame-Nummer, Frame-Startzeit und CPU-Zeit. Indem wir die Startzeit jedes Datensatzes berechnen, können wir das Intervall zwischen jeweils zwei Frames berechnen und bestimmen, ob die Bildrate der Animation 60 FPS erreichen kann.

Aber! Schauen Sie sich die allgemeine Kompatibilität der Web Performance Timing API an:

Obwohl die Frame Timing API gut ist, ist ihre Kompatibilität derzeit nicht sehr benutzerfreundlich. Nun, inwieweit ist sie unfreundlich? Eine Browserunterstützung gibt es noch nicht, es befindet sich im experimentellen Stadium und ist eine zukunftsweisende Programmierung. Willst du mich verarschen? Es ist völlig nutzlos, nachdem man so lange geredet hat …

Methode 3: Verwenden der requestAnimationFrame-API

Ich habe so viel Zeit damit verbracht, die Frame Timing API zu beschreiben, aber am Ende war sie aufgrund von Kompatibilitätsproblemen völlig unbrauchbar. Dies bedeutet jedoch nicht, dass eine so lange Beschreibung nutzlos ist. Aus der obigen Einführung wissen wir, dass, wenn wir in jedem Frame einen festen Zeitpunkt erhalten können, durch Subtrahieren der beiden auch die von einem Frame verbrauchte Zeit angenähert werden kann.

Versuchen wir es also mit einem anderen Ansatz. Dieses Mal verwenden wir die requestAnimationFrame-API, die eine gute Kompatibilität aufweist.

// Syntax window.requestAnimationFrame(callback);

Jeder sollte mit requestAnimationFrame vertraut sein. Die Methode teilt dem Browser mit, dass Sie eine Animation ausführen möchten, und fordert den Browser auf, eine angegebene Funktion aufzurufen, um die Animation vor dem nächsten Neuzeichnen zu aktualisieren.

Sie wenden diese Methode an, wenn Sie bereit sind, den Bildschirm zu aktualisieren. Dies erfordert, dass Ihre Animationsfunktion vor der nächsten Neuzeichnung des Browsers ausgeführt wird. Die Anzahl der Rückrufe liegt normalerweise bei 60 Mal pro Sekunde und die meisten Browser entsprechen normalerweise der vom W3C empfohlenen Aktualisierungsrate.

Prinzip der Verwendung von requestAnimationFrame zur Berechnung von FPS

Das Prinzip besteht darin, dass die Methode requestAnimationFrame normalerweise 60 Mal in einer Sekunde ausgeführt wird, d. h. ohne dass Frames verloren gehen. Angenommen, die Animation beginnt zum Zeitpunkt A, endet zum Zeitpunkt B und dauert x ms. Der requestAnimationFrame wird insgesamt n-mal ausgeführt, daher beträgt die Bildrate dieser Animation ungefähr: n / (B - A).

Der Kerncode lautet wie folgt. Damit lässt sich die Bildrate der Seite pro Sekunde ungefähr berechnen. Außerdem zeichnen wir einen allFrameCount auf, um die Häufigkeit der rAF-Ausführungen aufzuzeichnen, mit der die Bildrate jeder Animation berechnet wird:

var rAF = Funktion () {
    zurückkehren (
        Fenster.requestAnimationFrame ||
        Fenster.webkitRequestAnimationFrame ||
        Funktion (Rückruf) {
            window.setTimeout(Rückruf, 1000 / 60);
        }
    );
}();
  
var Rahmen = 0;
var allFrameCount = 0;
var letzte Zeit = Date.now();
var lastFameTime = Date.jetzt();
  
var Schleife = Funktion () {
    var jetzt = Date.jetzt();
    var fs = (jetzt - letzteFameTime);
    var fps = Math.round(1000 / fs);
  
    lastFameTime = jetzt;
    // Nicht auf 0 setzen, sondern die Differenz zwischen diesem Wert am Anfang und Ende der Animation aufzeichnen, um die FPS zu berechnen
    alleFrameCount++;
    Rahmen++;
  
    wenn (jetzt > 1000 + letzteZeit) {
        var fps = Math.round((Frame * 1000) / (jetzt - letzte Zeit));
        console.log(`${new Date()} FPS innerhalb von 1S:`, fps);
        Rahmen = 0;
        letzteZeit = jetzt;
    };
  
    rAF(Schleife);
}
 
Schleife();

OK, suchen Sie zu Testzwecken eine Seite mit einer kontinuierlich laufenden Animation. Sie sehen, dass der Code wie folgt ausgeführt wird:

Hier habe ich zum Testen eine Seite verwendet, die ich zuvor erstellt hatte. Ich habe Chrome verwendet, um gleichzeitig die FPS-Anzeige der Seite aufzurufen und die Echtzeit-FPS-Werte auf beiden Seiten zu vergleichen. Sie sind im Grunde konsistent.

Testseite, Sonnensystem. Sie können den obigen Code in die Konsole dieser Seite einfügen, um die Daten zu testen:

Wenn man die Bildrate in der oberen rechten Ecke vergleicht, ist die Bildrate im Wesentlichen gleich. In den meisten Fällen ermöglicht diese Methode eine gute Schätzung der Bildrate für Webanimationen.

Wenn wir die Bildrate eines bestimmten Animationsprozesses zählen müssen, müssen wir nur den Wert von allFrameCount am Anfang und am Ende der Animation aufzeichnen und ihn dann durch die in der Mitte verbrauchte Zeit teilen, um den FPS-Wert des bestimmten Animationsprozesses zu erhalten.

Es ist anzumerken, dass zwischen dem mit dieser Methode berechneten Ergebnis und der tatsächlichen Bildrate definitiv eine Diskrepanz besteht, da das Zeitintervall zwischen den Ausführungen von JavaScript durch den Haupt-Thread als ein Frame angesehen wird und nicht die vom Haupt-Thread plus dem Synthese-Thread verbrauchte Zeit als ein Frame, wie oben erwähnt. Aber für den gegenwärtigen Stand ist es eine akzeptable Methode.

Oben finden Sie Einzelheiten zur Berechnung der FPS von Webanimationen. Weitere Informationen zur Berechnung der FPS von Webanimationen finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!