Ir al contenido

Listeners de Raw Input en segundo plano en Windows 10 y Windows 11

En esta página

Respuesta breve: el límite del listener en segundo plano hasta aproximadamente 125 Hz está confirmado por nuestra medición física en Windows 11 24H2. Con el throttling del sistema activado, el intervalo medio de los WM_INPUT en segundo plano fue de 7,97 ms, o alrededor de 125,5 Hz; el foreground mantuvo 1,04 ms. Tras desactivar el mecanismo, el background volvió a 1,00 ms. En series virtuales concretas, el throttling no provocó pérdida de raw packets: se conservaron 32 de 32 y 256 de 256 eventos.

Estado: el mecanismo de throttling y coalescing de los listeners en segundo plano está documentado por Microsoft. La frecuencia de alrededor de 125 Hz fue medida por un tester público independiente con un ratón físico de 1000 Hz en Windows 11 24H2. La rama del sistema también se observó en Windows 11 25H2 y no se encontró en el Windows 10 22H2 comparado.

Microsoft describe la causa directamente: un ratón con high report rate enviaba la entrada no solo al juego, sino también a varios procesos en segundo plano. El procesamiento de esas solicitudes consumía un tiempo de CPU notable que podría haberse dedicado al renderizado, y en un Surface Laptop Studio de prueba con un ratón de 1000 Hz se observaron stutters considerables. La solución fueron el throttling, el coalescing y la limitación de la frecuencia de mensajes precisamente para los Raw Input listeners en segundo plano.

En el momento del lanzamiento del cambio, los ratones rápidos ya habían superado ampliamente los 1000 Hz. Por ejemplo, Razer lanzó un ratón con cable de 8000 Hz en 2021 y una tecnología inalámbrica de 4000 Hz en 2022. Un dispositivo de 8000 Hz puede enviar hasta ocho veces más informes por segundo que un dispositivo de 1000 Hz. Por eso, la difusión de ratones de 4000–8000 Hz aumentaba lógicamente la escala del problema con varios listeners en segundo plano.

La última frase es nuestra interpretación del contexto, no una declaración de Microsoft. Microsoft no calificó la actualización como una reacción de emergencia precisamente a ratones de 4000 u 8000 Hz, y en la prueba publicada utilizó un ratón de 1000 Hz. Además, es más correcto hablar del coste total de la entrega y el procesamiento de input requests, y no atribuir todo el efecto únicamente a las interrupciones de hardware.

El material está relacionado con el ajuste «Reducir la frecuencia de los eventos Raw Input en segundo plano». Limita precisamente los listeners en segundo plano y no debe describirse como una limitación de la entrada en foreground ni como un aumento garantizado de FPS.

Verificamos cinco afirmaciones:

  1. En Windows 11 existe un procesamiento separado de los Raw Input listeners en segundo plano de alta frecuencia.
  2. Este no está presente de la misma forma en el Windows 10 22H2 investigado.
  3. En Windows 11 24H2 la frecuencia efectiva del listener en segundo plano es realmente de alrededor de 125 Hz con un flujo de entrada de alrededor de 1000 Hz.
  4. El throttling puede reducir la integridad del flujo WM_INPUT del juego mediante pérdidas, unión o división de paquetes.
  5. Cambiar el modo de ventana por sí mismo crea un Raw Input path diferente.
  • Windows 10 22H2 build 19045.6456;
  • Windows 11 24H2 con un ratón físico de 1000 Hz;
  • Windows 11 25H2;
  • máquinas virtuales aisladas;
  • consumidores foreground y background;
  • registro habitual de Raw Input, RIDEV_NOLEGACY y RIDEV_INPUTSINK;
  • windowed, borderless y exclusive presentation confirmado;
  • series de control de 32 eventos y una serie separada de 256 eventos.

La serie física verificaba los intervalos entre WM_INPUT, pero no incluía una partida real, anti-cheat ni overlay. La serie virtual no reproducía el USB polling, la GPU física, el monitor ni la ruta click-to-photon.

En un experimento público independiente, RawMouseThrottleBufferTester registraba el ratón con RIDEV_INPUTSINK y medía los intervalos Stopwatch entre los mensajes de movimiento WM_INPUT. La misma ventana se comparó en foreground y background con los valores predeterminados del sistema, y después de desactivar el throttling.

El valor medio mostrado se calcula sobre una ventana circular de los últimos 512 intervalos recibidos. Los movimientos nulos y las pausas de 40 ms o más se descartaron. El campo Samples de la captura muestra el número total de intervalos recibidos en el momento de la captura, no el tamaño de la ventana estadística.

Además, los componentes del sistema de Windows 10 22H2 y Windows 11 25H2 se compararon estáticamente para encontrar una rama separada de procesamiento del ratón en segundo plano y separar el Raw Input path de las rutas legacy cursor y presentation.

Después, en entornos virtuales idénticos se envió una secuencia controlada de mouse events a un consumidor foreground o background. Para cada escenario se registraron el número de raw packets enviados y recibidos, las pérdidas, las uniones, las divisiones, el foreground state y, por separado, los eventos de la rama legacy/cursor.

Solo se modificaba un factor a la vez: el método de registro del consumidor, el foreground state, el modo de ventana o el perfil de throttling del sistema. Entre escenarios, el estado de prueba se devolvía al baseline registrado.

Estado Intervalo medio de los últimos 512 eventos Frecuencia equivalente Samples en la captura
Default, foreground 1,04 ms ≈962 Hz 2 221
Default, background 7,97 ms ≈125,5 Hz 3 556
Throttling desactivado, foreground 1,00 ms ≈1000 Hz 19 606
Throttling desactivado, background 1,00 ms ≈1000 Hz 12 009

Esto confirma alrededor de 125 Hz precisamente para el consumidor RIDEV_INPUTSINK en segundo plano en el Windows 11 24H2 investigado. La ruta foreground del mismo programa no estaba limitada a 125 Hz.

Escenario Windows 10 22H2 Windows 11 25H2 Resultado
Entrega básica de Raw Input 32 enviados, 32 recibidos 32 enviados, 32 recibidos No se detectaron pérdidas, merge ni split
Background sin RIDEV_INPUTSINK 0 de 32 0 de 32 Entrega en segundo plano no solicitada
Background con RIDEV_INPUTSINK 32 de 32 32 de 32 La entrega en segundo plano funciona en ambos SO
Windowed, borderless, exclusive 32 de 32 en cada modo 32 de 32 en cada modo El presentation mode no cambió la packet integrity
Perfiles de stress del throttling No aplicable 256 de 256 en todos los estados Cambió la rama legacy/cursor, pero no la integridad de WM_INPUT

RIDEV_INPUTSINK es un conmutador documentado de la entrega en segundo plano. Sin él, un consumidor background no debería recibir el mismo flujo que una aplicación foreground. El resultado nulo de esta fila no es una pérdida de datos de Windows.

En la serie de stress, los estados de throttling del sistema modificaron notablemente la cantidad de legacy events y el movimiento del cursor del sistema. Sin embargo, en todos los estados el consumidor de Raw Input recibió los mismos 256 paquetes de 256. Por eso, el efecto encontrado no puede describirse correctamente como «Windows 11 pierde Raw Input».

  • Microsoft añadió en Windows 11 throttling, coalescing y limitación de la frecuencia de mensajes para los raw mouse listeners en segundo plano.
  • En el Windows 11 24H2 investigado, el consumidor foreground físico recibía mensajes con un intervalo de alrededor de 1 ms, y el consumidor background con un intervalo de 7,97 ms, o alrededor de 125,5 Hz.
  • Tras desactivar el throttling, el intervalo del consumidor background volvió a 1,00 ms.
  • En el Windows 11 25H2 investigado se observa una rama separada de este procesamiento; en el par exacto de Windows 10 22H2 no se detectó.
  • RIDEV_INPUTSINK cambia la entrega en segundo plano de WM_INPUT en ambos SO investigados.
  • En todos los escenarios enumerados, la integridad de los raw packets se conservó 1:1.
  • Los cambios de throttling se manifestaron en la rama legacy/cursor medida, y no como pérdida de raw packets.
  • Que cada background listener en cada build de Windows 11 esté limitado siempre exactamente a 125,0 Hz. El resultado confirmado se refiere al Windows 11 24H2 descrito y al método de registro.
  • Que el mecanismo reduzca siempre los FPS, la latency o el stutter en cualquier equipo.
  • Que desactivar el throttling del sistema mejore el control del ratón.
  • Que DWM gestione la integridad de WM_INPUT en todos los juegos y builds de Windows 11.
  • Que una packet integrity idéntica garantice la misma latencia física click-to-photon o la misma sensación subjetiva de apuntado.
  • Que el resultado de la máquina virtual se traslade a cada ratón físico, juego, anti-cheat u overlay.

Las capturas físicas públicas no contienen el número exacto de build de Windows 11 24H2, el modelo del ratón, un CSV de todos los intervalos ni un orden automatizado de conmutación de estados. El valor medio refleja los últimos 512 eventos, y el movimiento del ratón se realizó manualmente. Por eso, el resultado confirma con seguridad el clúster observado de alrededor de 8 ms, pero no establece una constante exacta para cualquier sistema.

La máquina virtual permite repetir la ruta de software, pero no reproduce el USB polling, el microcontrolador del ratón, la GPU física, el monitor ni el ciclo de juego completo. Las series de 32 y 256 eventos son suficientes para verificar la integridad observada de una ruta concreta, pero no para estimar pérdidas raras de baja probabilidad.

Windows 11 25H2 se comparó con un único build exacto de Windows 10 22H2. El resultado no debe trasladarse automáticamente a versiones tempranas de Windows 11, Windows Server o actualizaciones futuras.

Para saber cómo repetir la parte dinámica de las observaciones, véase Cómo verificarlo por tu cuenta.

BoosterX desarrolla GameModeX y ProcessX, y este estudio y sus herramientas, incluido el RawMouseThrottleBufferTester público, pertenecen al desarrollador de BoosterX, por lo que tiene un interés directo en los resultados. La metodología y los límites de aplicabilidad se describen arriba, y las conclusiones pueden verificarse con datos abiertos: el código público de la herramienta, las capturas de las mediciones y las fuentes enumeradas. El resultado nulo en pérdidas de WM_INPUT, la confirmación de alrededor de 125 Hz y la ausencia de una garantía universal se publican juntos.

En Windows 11, deja el throttling del sistema de los raw mouse listeners en segundo plano en su estado predeterminado. Microsoft lo introdujo para reducir el trabajo de las aplicaciones en segundo plano al usar un ratón con high report rate, conservando la entrada precisa del juego en foreground.

Para un PC de juego, BoosterX recomienda limitar los background listeners compatibles a aproximadamente 50 Hz. La medición propia de este intervalo en BoosterX aún no se ha publicado; la cifra en sí concuerda con mediciones independientes públicas: según las comprobaciones de PC-Tuning y Noverse, un intervalo de alrededor de 20 ms corresponde a una frecuencia de un listener compatible de aproximadamente 50–60 Hz. Estos materiales se citan en las fuentes como una comparación adicional, y el valor medido en este artículo es la limitación del sistema de alrededor de 125 Hz, no la frecuencia tras el ajuste manual. Aumentar el intervalo reduce el número de eventos en segundo plano entregados y de ejecuciones del manejador al mover el ratón. La ventana en foreground en la ruta verificada conserva la entrada a plena velocidad.

La dirección de la optimización local está confirmada: reducir la frecuencia de entrega de los eventos en segundo plano disminuye tanto el número de dichas entregas como el número de ejecuciones del manejador. No se midieron el tamaño final del cambio en la carga total de CPU, los FPS o el frametime para un conjunto arbitrario de programas. La reacción en segundo plano de la aplicación al ratón puede volverse menos fluida, por lo que un listener que realmente necesite una alta frecuencia en background es motivo para volver al valor predeterminado de Windows. La descripción práctica y el estado exacto del registro se indican en la página «Reducir la frecuencia de los eventos Raw Input en segundo plano».

Si una aplicación en segundo plano concreta provoca stutters o un conflicto de entrada, primero actualízala o ciérrala. No desactives la optimización del sistema ni suspendas procesos sin una comparación reproducible.

La función legacy de limitación de listeners en segundo plano en GameModeX estaba destinada ante todo a Windows 10 y no es un sustituto del mecanismo del sistema de Windows 11. Para una configuración nueva se recomienda la solución compatible con Windows 11 y ProcessX.

El estudio se realizó en entornos virtuales aislados. Los estados de prueba modificados se devolvían al baseline registrado entre escenarios; al finalizar se utilizó el estado original de la máquina virtual. En un equipo de usuario, este artículo no recomienda modificar parámetros del sistema, por lo que no se requiere una acción de restauración aparte.

Fuentes públicas y formulaciones verificadas: 2026-08-24.

  • 2026-09-20: se reformuló la recomendación de alrededor de 50 Hz: la cifra se compara explícitamente con mediciones independientes públicas, se indica la ausencia de una medición propia publicada del intervalo; el descargo de responsabilidad sobre el conflicto de intereses se complementó con la pertenencia del estudio y las herramientas, y se añadió un enlace a la verificación por cuenta propia en la metodología.
  • 2026-08-25: se recomendaron 50 Hz para el escenario de juego como reducción confirmada del procesamiento en segundo plano; se conservó por separado el límite para el efecto numérico sobre la CPU total y los FPS.
  • 2026-08-24: se añadió el contexto documentado de la carga de CPU, el límite de la conclusión sobre ratones de 4000–8000 Hz y el escenario prudente de limitación manual de los background listeners a aproximadamente 50 Hz.
  • 2026-08-24: se añadió la medición física pública de Windows 11 24H2, que confirma alrededor de 125 Hz para el background listener; se conservó el límite de que esto no es una constante universal de cada build y registro.
  • 2026-08-24: se publicó la primera comparación de Windows 10 22H2 y Windows 11 25H2.