displaytime

Chi analizza le prestazioni nel gaming su PC tende a fissarsi sui frame times, e ci sono ottime ragioni per farlo. Un semplice numero medio di FPS può ingannare parecchio, mentre un grafico dei frame time mostra subito se un gioco sta consegnando i fotogrammi in modo regolare oppure se sta soffrendo di stutter, micro scatti, colli di bottiglia lato CPU o altre forme di andatura irregolare. Eppure, per quanto utili siano, c'è un problema grosso nel basarsi solo su di essi: non sempre raccontano cosa il giocatore vede davvero sul monitor. Oggi la questione è più rilevante che mai. Il gaming moderno su PC non è più una faccenda lineare in cui il gioco renderizza un fotogramma, lo presenta e il monitor lo mostra all'istante. Tra Variable Refresh Rate, V-Sync, limitatori esterni di framerate, framerate sbloccati che superano il refresh massimo del monitor, percorsi di presentazione in modalità borderless, scheduling a livello di driver e tecnologie di frame generation, il rapporto tra l'output del gioco e l'immagine finale può diventare sorprendentemente complicato. Ed è qui che entrano in gioco i display times. I frame times, o più precisamente MsBetweenPresents nella terminologia di Intel PresentMon, misurano il tempo tra due chiamate Present() dell'applicazione. In parole povere, ci dicono quanto spesso il gioco invia i fotogrammi. I display times, ovvero MsBetweenDisplayChange, misurano invece il tempo tra i cambiamenti reali dell'immagine visualizzata. Detto ancora più semplice: ci dicono ogni quanto cambia davvero l'immagine mostrata al giocatore. Entrambe le metriche sono valide, ma se la domanda è quanto un gioco appaia fluido sul proprio schermo, allora i display times sono spesso la misura migliore. Questo non significa che i frame times siano inutili. Tutt'altro. Restano preziosissimi per capire cosa sta facendo il motore di gioco. Se c'è stutter da compilazione degli shader, stalli lato CPU, intoppi nello streaming degli asset o un'andatura irregolare nella simulazione, i frame times lo evidenziano con grande chiarezza. Ma quando si tratta di giudicare la fluidità percepita, cioè la costanza con cui i fotogrammi arrivano allo schermo, bisogna guardare a ciò che raggiunge davvero il monitor, non solo a ciò che il gioco ha tentato di presentare. Display times vs frame time: limitatori esterni e il caso DLSS Frame Generation Per i test sono state eseguite catture con CapFrameX in una scena di Resident Evil Requiem, scelto perché è un titolo moderno, ben ottimizzato e con un comportamento dei frame time piuttosto regolare. Il bersaglio era di 120 FPS, pari a 8,33 ms, per il confronto tra V-Sync e limitatore esterno. Invece per la cattura con frame generation il framerate è stato lasciato libero. Il sistema usato montava un Intel Core i7-14700K, 32 GB di DDR5-7000 CL34, un SSD NVMe PCIe 4.0 da 2 TB e una NVIDIA GeForce RTX 4060 Laptop GPU da 8 GB, su Windows 11 25H2 con tutto aggiornato. Il V-Sync ha una pessima reputazione, e non senza motivo: può aumentare la latenza e causare stutter se il sistema non regge il refresh del monitor. Ma quando il gioco mantiene il target, allinea la presentazione al ciclo di refresh e produce un'andatura sullo schermo molto pulita. Nei grafici, infatti, il frame time con V-Sync appariva più frastagliato del previsto, lasciando intendere un'esperienza poco fluida. Il display time raccontava tutt'altro: le deviazioni dal target di 8,33 ms restavano nell'ordine di 0,1 o 0,15 ms, troppo piccole per essere percepite anche dai giocatori più sensibili. Con il limitatore RTSS Async usato senza V-Sync è successo il contrario. Il grafico dei frame time sembrava convincente, con valori vicini al target, ma il display time mostrava una consegna visiva molto meno costante. Durante i test il gioco presentava judder e tearing evidenti, del tutto assenti con il solo V-Sync attivo. Questo non rende RTSS un cattivo strumento, ma dimostra che un limitatore non va giudicato solo dal grafico dei present. Il caso più lampante resta DLSS Frame Generation. Sulle GPU GeForce RTX serie 40 e 50 supportate, l'andatura dei fotogrammi può avvenire dopo le chiamate Present() del gioco. Misurato con MsBetweenPresents, il run appariva pessimo, con 1% e 0,1% low disastrosi che suggerivano un frame pacing terribile. Riattivando MsBetweenDisplayChange, lo scenario cambiava completamente. I display times catturavano l'effettiva cadenza dei fotogrammi visibili, mostrando una consegna corretta come ci si aspetta da un percorso di frame generation ben funzionante. In questo tipo di pipeline i display times non sono una metrica secondaria, sono la metrica che meglio rappresenta ciò che arriva al giocatore. Un'ultima nota riguarda i video. Sembrerebbe ovvio usare confronti filmati per mostrare la fluidità, ma un normale video YouTube non è il mezzo adatto. Se il gameplay è stato catturato a oltre 120 FPS e poi mostrato online a 60 FPS, gran parte dell'informazione temporale che si vuole analizzare è già andata persa o nascosta. Per questo le prove restano i grafici delle catture CapFrameX analizzate. Fonte

displaytime

Display times vs frame time: la vera metrica della fluidità nel gaming PC