- Messungen auf einem 500-Hz-Display vom Klick bis zur Helligkeitsänderung auf dem Bildschirm zeigen: Selbst mit X11, VRR und
dxvk-low-latency zusammen sinkt der Median der End-to-End-Latenz gegenüber dem standardmäßigen Wayland nur um 0,72 ms
- Native Wayland ist 0,14 bis 0,22 ms langsamer als X11, während XWayland gegenüber nativem Wayland bis zu 3,13 ms zusätzlich hinzufügt und damit einen deutlich größeren Unterschied verursacht
- Variable Refresh Rate (VRR) verringerte in allen Vergleichen die Latenz um 0,26 bis 0,45 ms und verengte zugleich die Verteilung von p5 bis p95 von 2,6 bis 3,0 ms auf 2,1 bis 2,2 ms
dxvk-low-latency reduzierte bei FPS-Limit die Latenz um 0,10 bis 0,29 ms, ohne Limit um 0,84 ms; im zweiten Fall sank die FPS jedoch von 715 auf 670, während die GPU-Auslastung statt 100 % bei 95 bis 97 % blieb- Die Ergebnisse stammen aus optimalen Bedingungen mit stabilen FPS und CPU-Bottleneck sowie einer bestimmten Hard- und Software-Kombination; im realen Spielbetrieb können die Jitter-Reduktion durch VRR und die Unterdrückung der Render-Queue durch den Frame Pacer einen größeren Unterschied als der Median machen
Warum die Optimierungsratschläge direkt überprüft wurden
- Für Linux-Gaming gibt es unzählige Optimierungstipps: X11 statt Wayland nutzen, Compositing deaktivieren, einen auf Latenz optimierten DXVK-Fork verwenden, Kernel-Scheduler für Gaming einsetzen,
gamescope, gamemode und Umgebungsvariablen anwenden usw.
- In kompetitiven FPS-Spielen sind niedrige Latenz, konsistente Frametimes und hohe FPS wichtig, aber es ist schwer zu überprüfen, ob eine geänderte Einstellung tatsächlich verbessert oder nur Placebo bzw. kontraproduktiv ist
- Hardware, Gehäuse, Firmware, Analysecode und Rohdaten des Messgeräts sind im click2photon GitHub-Repository veröffentlicht
Das Messgerät vom Klick bis zur Bildänderung
- Das Gerät wird am Monitor befestigt, erzeugt per USB einen Mausklick und misst die End-to-End-Systemlatenz, bis ein Lichtsensor die Bildänderung erkennt
- Das ursprüngliche Design orientierte sich an den Schaltplänen des damals verfügbaren OSLTT; im Verlauf wurden auch Ideen aus m2p-latency und Open-Source-LDAT integriert
- Für den Bau waren Mikrocontroller, Löten, Arduino-Firmware, Integrationszeit, Transimpedanzverstärker, KiCad und Gehäusedesign nötig
- Ein Adafruit QT Py RP2040 arbeitet als USB-HID-Maus mit 1.000 Hz Polling und löst den Klick aus
- Unmittelbar nach dem Senden des Klicks werden etwa alle 24 µs Photodioden-Samples erfasst
- Pro Klick werden 12.000 Samples seriell an den Host geschickt und als CSV protokolliert
- Das Host-Tool berechnet für jeden Klick eine Basislinie und sucht das erste Sample, das ausreichend stark davon abweicht
- Da die Erfassungszeit für 12.000 Samples fest ist, lässt sich die Zeit vom Klickversand bis zur Helligkeitsänderung auf dem Bildschirm berechnen
Verglichene Anzeige- und Rendering-Konfigurationen
- X11 und natives Wayland wurden verglichen, um die Wahrnehmung zu prüfen, Wayland fühle sich langsamer an
- Verglichen wurde außerdem, ob Variable Refresh Rate (VRR) inklusive G-Sync und FreeSync aktiviert ist oder nicht
- Die Unterschiede zwischen dxvk-low-latency und standardmäßigem DXVK wurden gemessen
- Der Frame Pacer dieses Forks ist in das offizielle Paket
proton-cachyos integriert und wird mit PROTON_DXVK_LOWLATENCY=1 aktiviert
- Um zu prüfen, ob der Frame Pacer Frametimeschwankungen absorbiert und den Aufbau einer Render-Queue verhindert, wurden zusätzlich zwei Fälle ohne FPS-Limit aufgenommen
- In der statischen Spielszene gab es keine Frametimeschwankungen, und die Tests liefen unter CPU-Bottleneck-Bedingungen, wodurch reale Spielsitzungen nicht vollständig abgebildet werden
- In echten Sessions können Frametimes je nach Spielsituation oder Ressourcennutzung anderer Prozesse variieren
- Die Wayland-Tests liefen standardmäßig nativ unter Wayland mit
PROTON_ENABLE_WAYLAND=1; zum Vergleich wurden außerdem zwei XWayland-Fälle mit deaktiviertem VRR gemessen
Test-Hardware und Software
- Während der Tests war nur ein Display angeschlossen; die Hardware bestand aus:
- AMD Ryzen 7 5800X3D
- NVIDIA GeForce RTX 4070 SUPER
- 2× DDR4-3200-Module mit 8 GB
- MSI MAG 272QP QD-OLED X50, 2560×1440, 500 Hz
- MSI B450 GAMING PRO CARBON AC
- Der Software-Stack bestand aus CachyOS, Kernel 7.1.3-2-cachyos, NVIDIA-Treiber 610.43.03-1, KDE Plasma 6.7.2-1.1 und xorg-server 21.1.24-1.1
- Verwendet wurden
proton-cachyos-native 1:11.0.20260602-3 und dxvk 3.0
- Der standardmäßige Kernel-Scheduler von CachyOS blieb unverändert
Display- und DXVK-Einstellungen
- Die System-Bildwiederholrate war auf 500 Hz eingestellt
- Unter X11 wurden Flip-Mode und VRR per
nvidia-settings aktiviert; Änderungen an VRR erfordern einen Neustart
- Unter Wayland wird VRR in den KDE-Einstellungen aktiviert, ein Neustart ist nicht nötig
- Waylands Flip-Mode bzw. Direct Scan-Out wird nicht manuell gesetzt, sondern vom Compositor pro Frame entschieden
- Im Reiter Effects der KWin Debug Console wurde
showcompositing aktiviert
- Wenn nur das Spiel im Vollbild angezeigt und vollständig fokussiert war und am Rand kein roter Rahmen erschien, wurde dies als Flip-Mode gewertet
- Für jede Vergleichsbedingung wurde eine optimierte
dxvk.conf verwendet
- Bei deaktiviertem VRR:
dxgi.maxFrameRate = 500
- Bei aktiviertem VRR und deaktiviertem
dxvk-low-latency: dxgi.maxFrameRate = 497
- Wenn VRR und
dxvk-low-latency gemeinsam aktiv waren, wurde für 500 Hz folgendes Low-Latency-VRR-Frame-Pacing verwendet
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
- In allen Konfigurationen wurde
d3d11.cachedDynamicResources = "c" angewendet
Spielumgebung und wiederholtes Messverfahren
- Das Testspiel war das per Heroic und Proton gestartete DirectX-11-Spiel Diabotical
- Es wurden die native Auflösung und 100 % Render-Skalierung verwendet, Vsync deaktiviert und alle übrigen Grafikeinstellungen so weit wie möglich reduziert
- Ein versteckter Befehl zum kurzfristigen Ausblenden des UI wurde mit
/bind mouse_left testlatency auf die linke Maustaste gelegt; zusätzlich wurde ein HUD mit großem weißen Kasten eingerichtet, um den Helligkeitsunterschied beim Klick zu vergrößern
- Jeder Test wurde unter denselben Bedingungen wiederholt
- Unnötige Software wurde geschlossen, und ein lokaler Server im selben Modus auf derselben Karte wurde gestartet
- Die Maus wurde an einer festgelegten Position auf eine bestimmte Geländemarkierung ausgerichtet
- Über etwa 2 Minuten wurden 100 Klicks durchgeführt, insgesamt 3 Mal
- Die Szene blieb statisch, ohne Bots, andere Spieler, Bewegung oder Rundenneustarts
- Es wurde darauf geachtet, dass keine anderen relevanten Prozesse liefen und die Position des Messgeräts in allen Tests identisch blieb
Latenzbereich aller Konfigurationen
- Alle Fälle mit FPS-Limit hielten die Ziel-FPS stabil, und das Spiel befand sich während der gesamten Tests in einem CPU-Bottleneck
- Alle Fälle zeigten glockenförmige Verteilungen ohne große Ausreißer; die Spanne von p5 bis p95 lag bei etwa 2 bis 3 ms
- Die Mediane der 8 Hauptkonfigurationen lagen bei 4,21 bis 4,93 ms; der gesamte Abstand betrug damit nur 0,72 ms
- XWayland lag mit dem Median bis zu 3,13 ms über der entsprechenden nativen Wayland-Konfiguration und erreichte 8,06 ms gegenüber 4,93 ms
- In den Fällen ohne FPS-Limit senkte
dxvk-low-latency die Latenz gegenüber standardmäßigem DXVK um 0,84 ms
Der kleine Unterschied zwischen X11 und nativem Wayland
- X11 war in allen Konfigurationen schneller, aber der Unterschied war mit 0,14 bis 0,22 ms klein und reicht nicht aus, um die Wahrnehmung zu erklären, Wayland sei deutlich langsamer
- Low-Latency und VRR aktiv: X11 4,21 ms, Wayland 4,38 ms, Unterschied +0,17 ms
- Nur Low-Latency aktiv: X11 4,64 ms, Wayland 4,83 ms, Unterschied +0,19 ms
- Nur VRR aktiv: X11 4,45 ms, Wayland 4,67 ms, Unterschied +0,22 ms
- Beides deaktiviert: X11 4,79 ms, Wayland 4,93 ms, Unterschied +0,14 ms
- Auch die Form der Latenzverteilung beider Display-Server war sehr ähnlich
Auswirkungen von VRR auf Latenz und Verteilung
- VRR zeigte unter den Vergleichsfaktoren den größten Effekt und war in allen Kombinationen 0,26 bis 0,45 ms schneller
- X11 mit Low-Latency: von 4,64 ms auf 4,21 ms, also 0,43 ms weniger
- X11 mit standardmäßigem DXVK: von 4,79 ms auf 4,45 ms, also 0,34 ms weniger
- Wayland mit Low-Latency: von 4,83 ms auf 4,38 ms, also 0,45 ms weniger
- Wayland mit standardmäßigem DXVK: von 4,93 ms auf 4,67 ms, also 0,26 ms weniger
- Die Spanne zwischen p95 und p5 lag mit VRR bei 2,1 bis 2,2 ms, ohne VRR bei 2,6 bis 3,0 ms; auch die Latenzverteilung wurde also enger
- Mit VRR wird ein Frame gescannt, sobald er fertig ist, statt auf den nächsten Scan-Out-Slot zu warten; das Messresultat passt damit zur Funktionsweise
Wirkung und Kosten von dxvk-low-latency
- In den Fällen mit FPS-Limit verringerte
dxvk-low-latency die Latenz in allen Kombinationen; die durchschnittliche Verbesserung von 0,20 ms war ähnlich groß wie der durchschnittliche Unterschied von 0,18 ms zwischen X11 und Wayland
- X11 mit VRR: von 4,45 ms auf 4,21 ms, also 0,24 ms weniger
- X11 ohne VRR: von 4,79 ms auf 4,64 ms, also 0,15 ms weniger
- Wayland mit VRR: von 4,67 ms auf 4,38 ms, also 0,29 ms weniger
- Wayland ohne VRR: von 4,93 ms auf 4,83 ms, also 0,10 ms weniger
- Unter Bedingungen ohne FPS-Limit zeigte der Pacer einen deutlich stärkeren Effekt, indem er den Aufbau der Render-Queue verhinderte und ungleichmäßiges Frame Pacing abmilderte
- Die GPU wurde nicht vollständig ausgelastet, sondern nahe an einem GPU-Bottleneck gehalten
- Die GPU-Auslastung lag bei standardmäßigem DXVK bei 100 %, mit
dxvk-low-latency bei 95 bis 97 %
- Die Latenz sank von 5,27 ms auf 4,43 ms, also um 0,84 ms
- Die FPS sanken um 45 FPS, von 715 auf 670
Die große Zusatzlatenz durch XWayland
- Wenn im Heroic Launcher
Enable Wine-Wayland (Experimental) oder PROTON_ENABLE_WAYLAND=1 deaktiviert wird, läuft das Spiel über XWayland
- XWayland fügt gegenüber nativem Wayland deutlich mehr Latenz hinzu
- Low-Latency aktiv: von 4,83 ms auf 5,95 ms, also +1,12 ms
- Standard-DXVK: von 4,93 ms auf 8,06 ms, also +3,13 ms
- Die zusätzlichen 3,13 ms im Standard-DXVK-Fall waren größer als alle anderen gemessenen Effekte zusammen; dabei wurde nicht nur der Durchschnitt durch einige schlechte Frames erhöht, sondern die gesamte Verteilung verschoben
- Wird unter XWayland zusätzlich
dxvk-low-latency aktiviert, sinkt die Latenz um 2,11 ms – die größte Verbesserung aller Fälle
Gültigkeitsbereich der Ergebnisse und praktische Einordnung
- Die Messergebnisse beschränken sich auf optimale Bedingungen mit stabilem FPS-Limit, CPU-Bottleneck und statischer Szene sowie auf einen bestimmten Hard- und Software-Stack
- In anderen Umgebungen können die absoluten Latenzwerte abweichen, die Zu- und Abnahmen der einzelnen Konfigurationen dürften sich aber weitgehend übertragen lassen
- Bei Displays mit geringerer Bildwiederholrate könnten die Verbesserungen durch VRR und Low-Latency-Pacing größer ausfallen
- X11 war 0,14 bis 0,22 ms schneller als Wayland, doch laufende Optimierungen in KWin könnten diesen Abstand verringern; andere Wayland-Compositoren könnten bereits besser abschneiden
- Lässt man XWayland außen vor und kombiniert X11, VRR und
dxvk-low-latency, ist der Median 0,72 ms niedriger als in der Standard-Wayland-Konfiguration
- Der Medianunterschied ist klein, aber VRR reduziert Latenz-Jitter, und
dxvk-low-latency mildert Frametimeschwankungen und GPU-Bottlenecks, wie sie im realen Spielbetrieb auftreten
Ähnliche Projekte zur Messung von Eingabelatenz
1 Kommentare
Hacker-News-Kommentare
Das Gute an Linux ist, dass solche Analysen nicht nur möglich sind, sondern tatsächlich zu Verbesserungen im Ökosystem führen. Die Ergebnisse werden an Entwickler von Grafiksoftware und Paketbetreuer der Distributionen weitergegeben, während ein solcher Verbesserungsweg bei Microsoft schwer vorstellbar scheint
Ich habe lange Windows genutzt und bin vor Kurzem zu Linux gewechselt; mir gefiel, dass KDE Plasma flotter als Windows 11 ist und man bei Problemen selbst eingreifen und Dinge verbessern kann. Wenn man den Linux-Desktop eine Zeit lang nicht genutzt hat, würde ich Bazzite empfehlen, ein für Gaming abgestimmtes Fedora; auch ohne Spiele kann man damit schnell einen ausgereiften Desktop aufsetzen
Früher konnte man mit einer intuitiven Konfigurationsdatei alles nach Wunsch anpassen, heute gibt es unzählige Abstraktionsschichten für Themes, Icons, hellen Modus und dunklen Modus, und trotzdem ist es schwer, eine Kombination zu finden, die richtig funktioniert. Im hellen Modus erscheint graue Schrift auf hellgrauem Hintergrund, im dunklen Modus schwarze Schrift auf schwarzem Hintergrund, und je nach Theme wie Adwaita kann selbst ein PDF-Viewer Schwierigkeiten haben, Text- und Hintergrundfarben korrekt festzulegen
Kein Theme macht die Scrollbars ausreichend gut sichtbar oder unterscheidet aktive und inaktive Fenster klar durch Farben. Schon Windows 3.11 konnte Scrollbars, die Markierung des aktiven Fensters und die Anpassung von Farben besser; vor dem Überdesign war es also eher besser
Intel(https://www.techpowerup.com/312122/psa-intel-graphics-driver...) und Nvidia(https://nateshoffner.com/blog/2017/05/disable-nvidia-telemet...) sammeln solche Daten ebenfalls von zustimmenden Nutzern. Da es bei beiden jedoch ein Opt-in ist, gibt es möglicherweise nicht viele Daten von besonders engagierten Gamern
Es gibt viele schrittweise Veränderungen, doch oft bleibt man jahrelang in lokalen Optima stecken. Trotzdem ist es gut, dass man die internen Abläufe relativ leicht einsehen kann, und ich sehe nicht unbedingt, warum Windows und macOS zwingend Closed Source sein müssten
Vor einigen Monaten habe ich mein Hauptbetriebssystem und Gaming-Setup auf Fedora umgestellt, und insgesamt fühlte es sich flotter an als Windows; diese Messung hat einige meiner Fragen zur Eingabeverzögerung in Spielen beantwortet
Vor Kurzem bin ich auf das Wayland-basierte Hyprland umgestiegen und frage mich, wie sich die Ergebnisse dadurch verändern würden; da es immer populärer wird, wäre ein erneuter Test schön. Gamescope habe ich ebenfalls in Betracht gezogen, aber ich habe gehört, dass es mit Nvidia nicht gut funktioniert, und von einem spieloptimierten Kernel habe ich auch erst jetzt erfahren. In kompetitiven Fighting Games ist Eingabeverzögerung sehr wichtig, daher würde ich gern von ähnlichen Optimierungen hören
Beim Spielen gefiel mir Hyprland, und Details wie variable Bildwiederholrate und Tearing über Gamescope ließen sich leichter konfigurieren als früher mit AwesomeWM unter X11. Auch die Lua-Konfiguration fühlte sich für jemanden, der AwesomeWM genutzt hat, vertraut an
Da der Test mit einem 500-Hz-Display durchgeführt wurde, könnten viele Probleme, die auf Displays mit niedriger Bildwiederholrate auftreten, verdeckt worden sein. Dass XWayland 3 ms langsamer war, könnte bei dieser Bildwiederholrate auch bedeuten, dass es um ein ganzes Frame hinterherhinkte
Bei Tests mit 120 Hz oder 60 Hz ließe sich klarer zwischen kleinen Unterschieden im Ausführungszeitpunkt und dem größeren Effekt einer Verzögerung um ein ganzes Frame unterscheiden
Am Ende des Artikels wird zwar hinterfragt, warum Wayland als langsam wahrgenommen wird, aber das XWayland-Ergebnis könnte genau der Grund sein. Nutzer, die X11-Spiele unter Wayland ausgeführt haben, könnten eine spürbare Verzögerung erlebt haben. Es wäre gut, wenn es in verschiedenen Bereichen mehr solche Messungen aus der Praxis gäbe
Der Autor hat andere Störvariablen gut ausgeschlossen, aber Nutzer, die Wayland als langsamer empfanden, könnten von einer nicht optimierten Umgebung ausgegangen sein und beim Wechsel zu einer Low-Latency-Konfiguration zugleich auch einschlägige Einstellungen korrigiert haben
Anders als bei X11, wo Xorg praktisch überall die Standard-Referenzimplementierung ist und sich ähnlich verhält, sind die Unterschiede zwischen Wayland-Implementierungen groß. Es kann Compositoren geben, die langsamer sind als das im Test verwendete KDE Plasma, und andere, die schneller sind
Schon die Formulierung Wayland-Eingabelatenz vermischt verschiedene Ebenen, ähnlich wie
HTTP-Animationsflüssigkeit. Gemessen wurden in diesem Artikel Xorg, KWin und XWayland; andere X11- und Wayland-Implementierungen können andere Eigenschaften habenAllerdings ist die zusätzliche Verzögerung von XWayland verdächtig groß, zu groß, um sie einfach als bloßen Overhead abzutun
Besonders Emacs im pgtk-Modus funktioniert unter GNOME deutlich besser, während es unter KWin beim Scrollen viel CPU verbraucht und bei hoher Auflösung leicht verzögert wirkt
Es wäre auch sehr interessant zu sehen, wie ein Vergleich mit Windows auf derselben Hardware ausfiele
Beim Breaka Club wird dieses Problem direkt behandelt, indem Kindern mit einem modifizierten Overcooked 2! das Programmieren beigebracht wird
Da es schwierig ist, Mods auf Schulgeräten zu installieren, wird ein gemoddetes OC2 per WebRTC gestreamt, und die Kinder spielen in Mobile Safari auf dem iPad mit einem On-Screen-Gamepad. Die Spielinstanzen laufen in Docker-Containern auf Kubernetes/k3s auf älterer Nvidia-Hardware; da der Datenverkehr über das Internet und das Schulnetz geht, wird die Gesamtlatenz unter anderem mit Zero-Copy-Transfer per NVEnc und DMABuf reduziert
Aktuell erleben sie den zusätzlichen Eingabe-Overhead von XWayland, aber da die Eingabe über virtuelle Geräte erfolgt, kann sich das Verhalten unterscheiden. End-to-End-Optimierung ist schwierig, und die derzeitige Leistung ist akzeptabel. Video zum Programmieren mit OC2: https://www.youtube.com/watch?v=ITWSL5lTLig
Die OC2-Lizenzen werden in begrenzter Zahl gekauft und beim Start eines Pods jeweils zugewiesen; sind alle in Benutzung, spielen die Kinder ein anderes Spiel
Wenn unter X11 Compositing-Rendering verwendet wird und ein Vollbildfenster dem Compositor einen Unredirect-Hinweis sendet, kann dieser das Compositing aussetzen, solange keine anderen Elemente auf dem Bildschirm gezeichnet werden, und die Swapchain der Anwendung direkt auf den Bildschirm durchreichen. Das ist praktisch die optimale Methode und kaum weiter zu verbessern
Wenn ein anderes Fenster darüber erscheint oder der Compositor entscheidet, dass direkte Weitergabe nicht möglich ist, entsteht ein Zwischenschritt, bei dem das Anwendungsfenster und andere Elemente in einen temporären Puffer komponiert werden. Wenn die Unredirect-Funktion etwa dadurch fehlschlägt, dass ein Fenster 1 Pixel kleiner als die Bildschirmhöhe erzeugt wird, oder wenn XWayland verwendet wird, kann die Latenz steigen; das ist eine grundlegende Beschränkung, daher treten ähnliche Probleme auch bei Compositoren anderer Betriebssysteme auf
Wayland hat auch Display-Planes untersucht, bei denen die GPU-Hardware mehrere Ebenen direkt zusammensetzt. Damit könnte ein Spiel mit der maximalen Bildrate rendern, während darüberliegende Fenster auf einer separaten Ebene gezeichnet und ohne Nebenwirkungen zusammengesetzt werden; ob das in realen Produktivumgebungen tatsächlich genutzt wird, ist allerdings unklar
Während Konsolen tendenziell auf eine feste Bildrate und dynamische Auflösung setzen, neigen PCs dazu, die Auflösung festzuhalten und Bildrate sowie Frame-Zeiten dynamisch zu halten. Ich frage mich, wie das mit Latenz zusammenhängt
Besonders in kompetitiven Spielen wird oft eine Bildrate angestrebt, die weit über der Bildwiederholrate des Displays liegt, und ich bin nicht sicher, ob das ein echter Vorteil ist oder nur Einbildung
Entscheidend ist nicht, mehr Frames zu sehen, sondern aktuellere Informationen zu sehen. Man könnte das Rendering auch so spät starten, dass es direkt vor der Bildschirmaktualisierung endet, aber wenn man den Zeitpunkt auch nur knapp verpasst, entsteht heftiges Stottern, und weder die GPU-Laufzeit noch die Einreichungszeit der CPU-Aufgaben sind deterministisch
Ideal wäre es, keine unnötigen Frames zu erzeugen und das Rendering erst direkt vor der Bildschirmaktualisierung zu starten, aber wenn man die Deadline verpasst, kommt es zu sehr störendem Stottern
Ein neuer Frame kann sich mitten im Bildaufbau einschieben, wodurch Tearing entsteht, aber unterhalb der Trennlinie werden aktuellere Pixel angezeigt. Deshalb können in einem Monitor-Frame mehrere Render-Frames gemischt sein, und auch wenn das nicht so gut ist wie ein VRR-Display mit hoher Bildwiederholrate, reduziert es die Latenz. In Spielen, in denen Reaktionsgeschwindigkeit weniger wichtig ist, wird häufig VSync verwendet, um die Bildrate an die Bildwiederholrate anzupassen und Tearing zu vermeiden
Manche Spiele passen die Auflösung in Echtzeit an, um eine konstante Bildrate zu halten. Auf dem PC konnte man Spiele schon immer auch auf deutlich schwächerer Hardware als ursprünglich vorgesehen ausführen, niedrigere Bildraten waren kulturell eher akzeptiert, und wer unzufrieden war, konnte aufrüsten. Konsolen hatten keinen Upgrade-Pfad und mussten auf eine einzige Konfiguration optimiert werden; deshalb war es sinnvoller, die Auflösung zu senken, bevor die Leistung zu stark einbrach
Das bedeutet nicht, dass das Spiel mehr Eingabe-Events erhält, aber es kann Eingaben schneller verarbeiten und widerspiegeln. Es ist also keine Einbildung, allerdings mit stark abnehmendem Nutzen, und der Effekt hängt von Frame-Queue, VSync, variabler Bildwiederholrate, CPU- oder GPU-Bottlenecks sowie der Struktur der Eingabe-, Simulations- und Render-Schleifen ab
Der Autor versucht von Anfang an, Einbildung auszuschließen, aber ich habe den Eindruck, dass Latenz letztlich doch nach Gefühl und Nutzungserlebnis bewertet wird. Persönlich denke ich, dass das eigene Empfinden der letzte Test ist, und auch wenn Daten nützlich sind, um reale Latenz zu diagnostizieren und zu beheben, kann man sich bei den meisten UI/UX-Fragen ruhig auf Vorlieben und subjektives Empfinden verlassen
Wenn man zusätzlich weniger technische Bewertungen wie Sterne vergibt, kann das auch verhindern, dass Tests und Datenerhebung zu sehr in Methodik aufgehen. In sorgfältig konstruierten Tests können Leistungseinbruchsbedingungen, die im Alltagsbetrieb einer bestimmten Umgebung häufig auftreten, leicht fehlen