Listener Raw Input in background in Windows 10 e Windows 11

In questa pagina

Risposta breve: il limite del listener in background a circa 125 Hz è confermato dalla nostra misurazione fisica su Windows 11 24H2. Con il throttling di sistema attivo, l’intervallo medio degli WM_INPUT in background è risultato di 7,97 ms, ovvero circa 125,5 Hz; il foreground ha mantenuto 1,04 ms. Dopo la disattivazione del meccanismo, il background è tornato a 1,00 ms. In alcune serie virtuali il throttling non ha causato perdita di raw packets: si sono conservati 32 su 32 e 256 su 256 eventi.

Stato: il meccanismo di throttling e coalescing dei listener in background è documentato da Microsoft. La frequenza di circa 125 Hz è stata misurata da un tester pubblico separato con un mouse fisico a 1000 Hz su Windows 11 24H2. Il ramo di sistema è stato osservato anche su Windows 11 25H2 e non è stato trovato nella Windows 10 22H2 messa a confronto.

Perché Microsoft ha aggiunto il limite

Microsoft descrive direttamente la causa: un mouse con high report rate inviava input non solo al gioco, ma anche a diversi processi in background. L’elaborazione di queste richieste occupava una quantità notevole di tempo CPU, che poteva essere speso per il rendering, e sul Surface Laptop Studio di test con un mouse a 1000 Hz si osservavano stutter significativi. La soluzione è diventata il throttling, il coalescing e la limitazione della frequenza dei messaggi proprio per i Raw Input listener in background.

Al momento dell’uscita della modifica, i mouse veloci avevano già superato di gran lunga i 1000 Hz. Ad esempio, Razer ha rilasciato un mouse cablato a 8000 Hz nel 2021 e una tecnologia wireless a 4000 Hz nel 2022. Un dispositivo a 8000 Hz è in grado di inviare fino a otto volte più report al secondo rispetto a un dispositivo a 1000 Hz. Pertanto la diffusione dei mouse a 4000–8000 Hz aumentava logicamente la portata del problema con più listener in background.

L’ultima frase è una nostra interpretazione del contesto, non una dichiarazione di Microsoft. Microsoft non ha definito l’aggiornamento una reazione d’emergenza proprio ai mouse a 4000 o 8000 Hz, e nel test pubblicato ha utilizzato un mouse a 1000 Hz. Inoltre è più corretto parlare del costo complessivo di consegna e di elaborazione delle input requests, anziché attribuire l’intero effetto solo agli interrupt hardware.

Impostazioni BoosterX correlate

Il materiale è correlato all’impostazione «Ridurre la frequenza degli eventi Raw Input in background». Essa limita proprio i listener in background e non deve essere descritta come una limitazione dell’input in foreground o come un aumento garantito degli FPS.

Affermazione verificabile

Abbiamo verificato cinque affermazioni:

In Windows 11 esiste un’elaborazione separata dei Raw Input listener in background ad alta frequenza.
Essa è assente nella stessa forma nella Windows 10 22H2 esaminata.
In Windows 11 24H2 la frequenza effettiva del listener in background è effettivamente di circa 125 Hz con un flusso in ingresso di circa 1000 Hz.
Il throttling può ridurre l’integrità del flusso WM_INPUT del gioco a causa di perdite, unione o suddivisione dei pacchetti.
Il cambio di modalità della finestra di per sé crea un diverso Raw Input path.

Ambito della ricerca

Windows 10 22H2 build 19045.6456;
Windows 11 24H2 con mouse fisico a 1000 Hz;
Windows 11 25H2;
macchine virtuali isolate;
consumer in foreground e in background;
registrazione Raw Input ordinaria, RIDEV_NOLEGACY e RIDEV_INPUTSINK;
windowed, borderless ed exclusive presentation confermato;
serie di controllo da 32 eventi e serie separata da 256 eventi.

La serie fisica verificava gli intervalli tra WM_INPUT, ma non includeva una partita reale, anti-cheat o overlay. La serie virtuale non riproduceva l’USB polling, la GPU fisica, il display o il percorso click-to-photon.

Metodologia

In un esperimento pubblico separato, RawMouseThrottleBufferTester registrava un mouse con RIDEV_INPUTSINK e misurava gli intervalli Stopwatch tra i messaggi di movimento WM_INPUT. La stessa finestra veniva confrontata in foreground e in background con i valori di sistema predefiniti, poi dopo la disattivazione del throttling.

Il valore medio mostrato è calcolato su una finestra circolare degli ultimi 512 intervalli ricevuti. I movimenti nulli e le pause da 40 ms venivano scartati. Il campo Samples nello screenshot mostra il numero totale di intervalli ricevuti al momento della cattura, non la dimensione della finestra statistica.

Inoltre, i componenti di sistema di Windows 10 22H2 e Windows 11 25H2 sono stati confrontati staticamente, per trovare un ramo separato di elaborazione del mouse in background e separare il Raw Input path dai legacy cursor e presentation paths.

Poi, in ambienti virtuali identici, una sequenza controllata di mouse events veniva inviata a un consumer in foreground o in background. Per ogni scenario venivano registrati il numero di raw packets inviati e ricevuti, perdite, unioni, suddivisioni, foreground state e separatamente gli eventi del ramo legacy/cursor.

Si modificava un solo fattore alla volta: il metodo di registrazione del consumer, il foreground state, la modalità della finestra o il profilo di throttling di sistema. Tra gli scenari lo stato di test veniva riportato al baseline registrato.

Risultati

Mouse fisico, Windows 11 24H2

Stato	Intervallo medio degli ultimi 512 eventi	Frequenza equivalente	Samples nella cattura
Default, foreground	1,04 ms	≈962 Hz	2 221
Default, background	7,97 ms	≈125,5 Hz	3 556
Throttling disattivato, foreground	1,00 ms	≈1000 Hz	19 606
Throttling disattivato, background	1,00 ms	≈1000 Hz	12 009

Questo conferma circa 125 Hz proprio per il consumer RIDEV_INPUTSINK in background nella Windows 11 24H2 esaminata. Il percorso foreground dello stesso programma non è stato limitato a 125 Hz.

Scenari virtuali controllati

Scenario	Windows 10 22H2	Windows 11 25H2	Risultato
Consegna Raw Input di base	32 inviati, 32 ricevuti	32 inviati, 32 ricevuti	Nessuna perdita, merge o split rilevati
Background senza `RIDEV_INPUTSINK`	0 su 32	0 su 32	Consegna in background non richiesta
Background con `RIDEV_INPUTSINK`	32 su 32	32 su 32	La consegna in background funziona su entrambi i sistemi operativi
Windowed, borderless, exclusive	32 su 32 in ogni modalità	32 su 32 in ogni modalità	La presentation mode non ha modificato la packet integrity
Profili di throttling stress	Non applicabile	256 su 256 in tutti gli stati	È cambiato il ramo legacy/cursor, ma non l’integrità `WM_INPUT`

RIDEV_INPUTSINK è un interruttore documentato della consegna in background. Senza di esso, un consumer in background non deve ricevere lo stesso flusso dell’applicazione in foreground. Il risultato nullo in questa riga non è una perdita di dati di Windows.

Nella serie stress gli stati di throttling di sistema modificavano in modo evidente il numero di legacy events e il movimento del cursore di sistema. Tuttavia, in tutti gli stati il consumer Raw Input ha ricevuto gli stessi 256 pacchetti su 256. Pertanto l’effetto rilevato non può essere descritto correttamente come «Windows 11 perde Raw Input».

Cosa è confermato

Microsoft ha aggiunto in Windows 11 throttling, coalescing e limitazione della frequenza dei messaggi per i raw mouse listener in background.
Nella Windows 11 24H2 esaminata, il consumer fisico in foreground riceveva messaggi con un intervallo di circa 1 ms, mentre il consumer in background con un intervallo di 7,97 ms, ovvero circa 125,5 Hz.
Dopo la disattivazione del throttling, l’intervallo del consumer in background è tornato a 1,00 ms.
Nella Windows 11 25H2 esaminata si osserva un ramo separato di questa elaborazione; nella coppia esatta Windows 10 22H2 non è stato rilevato.
RIDEV_INPUTSINK cambia la consegna in background WM_INPUT su entrambi i sistemi operativi esaminati.
In tutti gli scenari elencati l’integrità dei raw packets si è conservata 1:1.
Le modifiche del throttling si sono manifestate nel ramo legacy/cursor misurato, non come perdita di raw packets.

Cosa non è confermato

Che ogni listener in background su ogni build di Windows 11 sia sempre limitato esattamente a 125,0 Hz. Il risultato confermato riguarda la Windows 11 24H2 descritta e il metodo di registrazione.
Che il meccanismo riduca sempre FPS, latency o stutter su qualsiasi computer.
Che la disattivazione del throttling di sistema migliori il controllo del mouse.
Che DWM gestisca l’integrità WM_INPUT in tutti i giochi e le build di Windows 11.
Che un’identica packet integrity garantisca un’identica click-to-photon latency fisica o una sensazione soggettiva di puntamento.
Che il risultato di una macchina virtuale si trasferisca a ogni mouse fisico, gioco, anti-cheat o overlay.

Limitazioni

Le catture fisiche pubbliche non contengono il numero esatto di build di Windows 11 24H2, il modello del mouse, il CSV di tutti gli intervalli o un ordine automatizzato di commutazione degli stati. Il valore medio riflette gli ultimi 512 eventi, e il movimento del mouse è stato eseguito manualmente. Pertanto il risultato conferma con sicurezza il cluster osservato intorno a 8 ms, ma non definisce una costante esatta per qualsiasi sistema.

La macchina virtuale consente di ripetere il percorso software, ma non riproduce l’USB polling, il microcontrollore del mouse, la GPU fisica, il display e l’intero ciclo di gioco. Le serie da 32 e 256 eventi sono sufficienti per verificare l’integrità osservabile di un percorso specifico, ma non per valutare perdite rare con bassa probabilità.

Windows 11 25H2 è stata confrontata con una sola build esatta di Windows 10 22H2. Il risultato non va trasferito automaticamente alle prime versioni di Windows 11, a Windows Server o a futuri aggiornamenti.

Per come ripetere la parte dinamica delle osservazioni — vedi Come verificare autonomamente.

BoosterX sviluppa GameModeX e ProcessX, e questa ricerca e i suoi strumenti, incluso il RawMouseThrottleBufferTester pubblico, appartengono allo sviluppatore di BoosterX, quindi egli ha un interesse diretto nei risultati. La metodologia e i limiti di applicabilità sono descritti sopra, e le conclusioni possono essere verificate tramite dati aperti: il codice pubblico dello strumento, le catture delle misurazioni e le fonti elencate. Il risultato nullo sulle perdite WM_INPUT, la conferma di circa 125 Hz e l’assenza di una garanzia universale sono pubblicati insieme.

Conclusione pratica

Su Windows 11 lasciate il throttling di sistema dei raw mouse listener in background nello stato predefinito. Microsoft lo ha introdotto per ridurre il lavoro delle applicazioni in background quando si utilizza un mouse con high report rate, preservando l’input preciso del gioco in foreground.

Per un PC da gaming BoosterX consiglia di limitare i listener in background compatibili a circa 50 Hz. Una misurazione propria di questo intervallo in BoosterX non è ancora stata pubblicata; il numero stesso è coerente con misurazioni indipendenti pubbliche: secondo le verifiche di PC-Tuning e Noverse, un intervallo di circa 20 ms corrisponde a una frequenza del listener compatibile di circa 50–60 Hz. Questi materiali sono riportati nelle fonti come ulteriore confronto, mentre il valore misurato in questo articolo è il limite di sistema di circa 125 Hz, non la frequenza dopo la configurazione manuale. L’aumento dell’intervallo riduce il numero di eventi in background consegnati e di avvii del gestore durante il movimento del mouse. La finestra in foreground nel percorso verificato mantiene l’input a piena velocità.

La direzione dell’ottimizzazione locale è confermata: la riduzione della frequenza di consegna degli eventi in background diminuisce sia il numero di tali consegne sia il numero di avvii del gestore. Non sono stati misurati la dimensione finale della variazione del carico CPU complessivo, degli FPS o del frametime per un insieme arbitrario di programmi. La reazione in background dell’applicazione al mouse può diventare meno fluida, quindi un listener che necessita davvero di un’alta frequenza in background è un motivo per ripristinare il default di Windows. La descrizione pratica e lo stato esatto del registro sono riportati nella pagina «Ridurre la frequenza degli eventi Raw Input in background».

Se una specifica applicazione in background causa stutter o conflitti di input, aggiornatela o chiudetela per prima. Non disattivate l’ottimizzazione di sistema e non sospendete i processi senza un confronto riproducibile.

La funzione legacy di limitazione dei listener in background in GameModeX era destinata principalmente a Windows 10 e non è un sostituto del meccanismo di sistema di Windows 11. Per la nuova configurazione si consiglia la soluzione supportata da Windows 11 e ProcessX.

Ripristino dello stato

La ricerca è stata eseguita in ambienti virtuali isolati. Gli stati di test modificati venivano riportati al baseline registrato tra gli scenari; al termine si utilizzava lo stato originale della macchina virtuale. Sul computer dell’utente questo articolo non consiglia di modificare i parametri di sistema, quindi non è richiesta un’azione di ripristino separata.

Fonti primarie pubbliche

RawMouseThrottleBufferTester — programma pubblico, codice sorgente, osservazione statica, verifica WinDbg e quattro catture della misurazione fisica su Windows 11 24H2.
Default, foreground e default, background — 1,04 ms contro 7,97 ms.
Throttling off, foreground e throttling off, background — 1,00 ms ciascuno.
Microsoft: Reduced game stutter with high report rate mice — throttling, coalescing e cap per i background raw mouse listener.
Microsoft: KB5027303, OS build 22621.1928 — primo aggiornamento preview stabile con miglioramento per i mouse ad high report rate.
Microsoft: Windows 11 Insider Preview Build 23424 — prima descrizione pubblica del miglioramento per il mouse ad high report rate durante il gioco.
Razer: lancio di Viper 8KHz — annuncio ufficiale del mouse a 8000 Hz del 28 gennaio 2021 e confronto del volume di report con 1000 Hz.
Razer: sviluppo di 4000 e 8000 Hz — timeline ufficiale dei dispositivi cablati e wireless ad high polling rate.
PC-Tuning: verifica dell’intervallo del background listener — metodologia pubblica di osservazione dell’intervallo e intervallo RawMouseThrottleDuration.
Noverse: verifica indipendente di due background listener — con un intervallo di 20 ms il listener compatibile è stato misurato a circa 60 Hz, mentre il listener con registrazione bypass ha mantenuto circa 1000 Hz.
Microsoft: RAWINPUTDEVICE — scopo di RIDEV_INPUTSINK e RIDEV_NOLEGACY.
Microsoft: About Raw Input — modello di registrazione e consegna di WM_INPUT.

Fonti pubbliche e formulazioni verificate: 2026-08-24.

Cronologia delle modifiche

2026-09-20: riformulata la raccomandazione di circa 50 Hz: il numero è esplicitamente confrontato con misurazioni indipendenti pubbliche, è indicata l’assenza di una propria misurazione pubblicata dell’intervallo; il disclaimer sul conflitto di interessi è integrato con l’appartenenza della ricerca e degli strumenti, aggiunto il link alla verifica autonoma nella metodologia.
2026-08-25: 50 Hz consigliati per lo scenario di gioco come riduzione confermata dell’elaborazione in background; mantenuto separatamente il limite per l’effetto numerico su CPU complessiva e FPS.
2026-08-24: aggiunto il contesto documentato del carico CPU, il limite della conclusione sui mouse a 4000–8000 Hz e lo scenario prudente di limitazione manuale dei listener in background a circa 50 Hz.
2026-08-24: aggiunta la misurazione fisica pubblica su Windows 11 24H2, che conferma circa 125 Hz per il background listener; mantenuto il limite che non è una costante universale di ogni build e registrazione.
2026-08-24: pubblicato il primo confronto tra Windows 10 22H2 e Windows 11 25H2.