"voel je dat in de praktijk niet", dat is een mooie vraag. Want je zou verwachten dat 24ms latency op je PC hetzelfde is als 24ms latency op je handheld; die latency is natuurlijk identiek maar zo voelt het niet. Doordat je een kleiner scherm hebt zie je minder verschillen dus je voelt latency lastiger, vooral als die consistent is. Zo heeft Crysis 3 remastered op de Steamdeck (LCD), ja: native gameplay (geen streaming), een button->pixel lag/latency van... 97ms. Zie ook:
https://linuxgamingcentral.org/posts/steam-deck-oled-has-less-input-lag/
De latency die ik in mijn vorige post heb vermeld was het verschil tussen wat ik op mijn PC zag en op mijn handheld, dus dat is net iets anders dan button->pixel latency.
Persoonlijk vind ik die 24ms veel, maar in praktijk loop je dan 2~3 frames achter op wat je op je PC ziet. Met 60 frames per seconde kijk je dus naar frame 57 ipv. 60 op je PC, dat valt wel mee. Zodra je daar een bluetooth controller bij gaat tellen, dan krijg je een extra vertraging van bijvoorbeeld 16ms (dus 1~2 frames, totaal 40ms/5frames). Tussen 30ms en 50ms voelt het goed speelbaar, boven de 150ms voelt al bijna onspeelbaar. Vooral als deze latency veel varieert. Het hangt ook echt af van het type spel dat je speelt. Een first person shooter kan met 40ms al heel traag aanvoelen, terwijl het oké is voor een platformer, en een turn-based game of een puzzelspel maakt een hoge latency al veel minder uit.
Als je direct op je PC speelt heb je praktisch geen vertraging. Je controller input, zelfs die 16ms van bluetooth, valt soms binnen je eigen framerate. Je PC berekend je logica en je frame binnen die 16ms (60Hz). Dus je knop->frame interactie is voor je gevoel instantaan. Een gaming monitor heeft in het transport eigenlijk geen vertraging, een standaard monitor kan soms wat 'image enhancement' doen en dat kan 5~10ms toevoegen. Een TV kan soms aan fancy video-processing doen, dit kost 50~100ms of meer, wat gaming soms onmogelijk maakt (hangt dus van het type spel af). Vandaar dat ze vaak een game-mode hebben die deze processing stap over kan slaan. Zodra een monitor je data heeft ontvangen moet hij deze nog op je scherm laten zien, dus je pixel fysiek op je scherm veranderen. Dit kost op een gaming monitor bijna geen tijd, <1ms~3ms. Op een traag scherm misschien 8ms.
Tel je die button->pixel lag/latency op voor game-PC met 60Hz (16ms): ideale synchronisatie controller (16ms) + PC->monitor (1ms), pixel-response (1ms) = 18ms latency. Voor een game-PC aangesloten op je kantoor-monitor zit je dan mogelijk op 29ms, en als je een TV gebruikt zonder game-mode zit je mogelijk flink boven de 66ms.
Op de Steam Deck komt de vertraging niet door je hardware, die is lekker vlot. De vertraging zit in de display server (Gamescope) die V-sync gebruikt en zo ~2 frames buffert (~33ms latency). Het OLED model op 90Hz heeft daar dan dus iets minder last van. Mocht je de frame-limiter optie gebruiken krijg je nog meer latency. Mocht je de laagste latency willen op je Steam Deck zul je de "Frame Limit" uit moeten zetten en 'Allow tearing' aan (dus V-sync uit). Zover ik weet doet VRR hier niets, alleen met een extern scherm. Mocht je ook nog vanaf je PC gaan streamen, dan zal die AV1 codec iets van de latency af halen maar de winst zit hem puur in het verzenden van minder bits. Het nadeel is dat je PC die AV1 codec encoding via hardware moet ondersteunen en je Steam Deck AV1 in hardware moet kunnen decoden (die zit er in, maar niet in mijn ARM+Linux handheld waardoor zelfs h264 decoding CPU vreet en meer latency geeft).