Wie wir Eingabeverzögerung messen

Zwei Gründe. Erstens kostet diese Ausrüstung 500 USD aufwärts und erfordert eine physische Einrichtung an jedem Controller, was für ein browserbasiertes Tool, das jeder in zehn Sekunden nutzen kann, nicht machbar ist. Zweitens messen hardware-instrumentierte Tests eine grundlegend andere Größe (Daumen-zu-Photon), die die Display-Latenz einschließt, die je nach Monitor variiert. Unsere Messung isoliert eine Komponente der Input-Kette, die Polling-Schleifen-Delta, die über Sitzungen und Controller auf derselben Host-Maschine vergleichbar ist. Anderes Werkzeug, anderer Job.

Das 10-Sekunden-Fenster bringt zwei konkurrierende Bedürfnisse in Balance. Lang genug, um bei einem aktiv bedienten Controller 200-500 gültige Deltas zu sammeln (dichte Eingabe liefert dichte Samples); kurz genug, damit Nutzer den Test tatsächlich abschließen, statt zu langweilen und vorzeitig abzubrechen. Beim Testen änderte eine Verlängerung des Fensters auf 30 Sekunden den gemeldeten Mittelwert bei stabilen Controllern um weniger als 5%, die Stichprobengröße ist bereits bei 10 Sekunden groß genug für statistische Signifikanz.

Unter 30 Samples ist der Standardfehler des Mittelwerts so groß, dass die Angabe einer spezifischen Latenzzahl eine trügerische Genauigkeit suggeriert. Beendet der Tester das Fenster mit weniger als 30 gültigen Deltas, verwirft er den Durchlauf stillschweigend und setzt den Nutzer in den Bereitschaftszustand zurück, ein Signal, den Test mit mehr durchgehender Eingabe zu wiederholen. Diese Schwelle entspricht der sampleCount < 30-Prüfung in scoreLatency() aus der Controller Health Score-Bewertungsbibliothek.

Die Gamepad API meldet Gleitkommazahlen für Achsenwerte, die selbst bei einem bewegungslosen Stick von Frame zu Frame leicht schwanken können. Eine sehr kleine Schwelle könnte Sensorschwankungen oder Stick Drift als wiederholte Eingabeänderungen werten, was das beobachtete Intervall nach unten verzerren würde. GPADLAB verwendet daher 0.02 als Implementierungsschwelle, um Rauschen zu reduzieren, aber gleichzeitig auf bewusste Stickbewegungen zu reagieren. Es handelt sich um eine pragmatische Änderungs-Erkennungsschwelle und nicht um einen Hardware-Kalibrierungswert.

Bei dieser Inter-Ereignis-Methode deutet ein Delta über 500 ms meist auf eine lange Pause zwischen benutzergenerierten Zustandsänderungen hin und nicht auf eine dichte Eingabesequenz, die für die Berechnung geeignet wäre. Die Einbeziehung dieser Pausen würde den Durchschnitt stark davon abhängig machen, wie durchgehend der Nutzer die Sticks bewegt oder Tasten gedrückt hat. GPADLAB schließt daher Deltas über 500 ms von dieser Berechnung aus; der cutoff ist eine Eingabe-Sampling-Regel und keine Aussage über die maximal mögliche Hardware-Latenz eines Controllers.

Latenzangaben von Erstentwicklern, wenn sie veröffentlicht werden, können mit Hardware-Setups oder Definitionen gemessen worden sein, die nicht direkt mit dieser browserbasierten Methode vergleichbar sind. GPADLAB-Ergebnisse sind am nützlichsten als Vergleichssignal, wenn derselbe Host, derselbe Browser, dieselben Verbindungsbedingungen, dasselbe Testverfahren und wiederholte Durchläufe verwendet werden. Ein Unterschied zwischen zwei einzelnen Durchläufen sollte nicht automatisch als Latenzunterschied auf Hardware-Ebene behandelt werden, weil requestAnimationFrame-Cadence, Browser-Planung, das Eingabemuster des Nutzers und die Systemlast die beobachteten Werte beeinflussen können.

Ja, das ist die wichtigste Einschränkung. Chrome, Firefox und Safari drosseln die requestAnimationFrame-Callbacks in Hintergrund-Tabs auf 1 fps oder weniger. Ein Test in einem Hintergrund-Tab liefert daher sinnlose Ergebnisse. Der Tester benötigt einen aktiven Vordergrund-Tab. Wir beschränken den Test derzeit noch nicht auf die Dokumentsichtbarkeit, aber diese Prüfung steht auf dem Polish-Backlog. Führe den Test also auf dem aktiven Tab aus und wechsle während des 10-Sekunden-Fensters nicht den Tab.