Latencia en Linux: X11 vs Wayland

Si usas Linux para trabajar o jugar, seguro ya te topaste con la misma discusión de siempre: X11 o Wayland. La conversación suele quedarse en frases sueltas, pero casi nunca baja a lo que de verdad te importa: cuánta latencia percibes cuando mueves el mouse, cuánto tarda en responder una ventana y qué cambia cuando activas VRR o juegas con DXVK.

Aquí vamos a aterrizar ese tema con una idea simple: no te sirve saber solo qué protocolo “es mejor”; te sirve entender en qué escenario uno responde antes que el otro, cuándo la diferencia es pequeña y cuándo sí la notas en uso real. Eso aplica igual si estás en una laptop de oficina en Quito, una PC de escritorio en Ciudad de México o una máquina de gaming en Buenos Aires.

Qué medimos cuando hablamos de latencia

La latencia de entrada no es una sola cifra mágica. En la práctica, hay varias capas entre tu clic y lo que ves en pantalla: el dispositivo envía el evento, el compositor o servidor gráfico lo procesa, la app actualiza el frame y el monitor lo presenta. Si una de esas etapas se alarga, tú lo sientes como una respuesta más pesada.

Para no mezclar conceptos, conviene separar tres cosas. La primera es la latencia de entrada del sistema, que es el tiempo desde que mueves el mouse o presionas una tecla hasta que el sistema refleja ese cambio. La segunda es la latencia de presentación, que depende del frame timing y del refresco del monitor. La tercera es la latencia percibida, que es la suma de todo eso más tu contexto: si estás editando texto, quizá toleras más; si juegas un shooter, cada milisegundo se nota más.

En Linux, el debate X11 vs Wayland toca precisamente esa cadena. X11 funciona con un modelo antiguo, donde el servidor X administra la comunicación de entrada y dibujo. Wayland delega más trabajo al compositor, que puede tomar decisiones más directas sobre cuándo presentar un frame. Eso no significa que Wayland siempre sea más rápido, pero sí que el camino de los eventos puede ser más corto y más predecible en muchos casos.

Por qué la percepción importa más que el número bruto

Un sistema puede medir 8 ms menos en una prueba sintética y aun así sentirse peor si tiene picos de latencia o frames irregulares. En cambio, otro puede tener un promedio un poco más alto pero mantenerse estable y sentirse más suave. Por eso, cuando hablamos de escritorio y gaming, conviene mirar promedio, p95 y consistencia, no solo el mínimo.

En la documentación de Wayland y de varios compositores modernos, el foco está justamente en la sincronización con el monitor y en evitar pasos innecesarios. Puedes revisar la base conceptual en la documentación de Wayland y, si usas KDE o GNOME, en sus docs oficiales sobre compositor y soporte de sesión. No necesitas memorizar cada detalle para tomar decisiones, pero sí entender que la arquitectura cambia el comportamiento.

X11 y Wayland: qué cambia de verdad

X11 nació para una era distinta: redes lentas, hardware limitado y una filosofía de servidor gráfico centralizado. Eso le dio mucha flexibilidad, pero también heredó una cadena de procesamiento que hoy puede ser menos eficiente para algunos usos. Wayland, en cambio, busca simplificar el camino entre app, compositor y pantalla.

En términos prácticos, X11 suele pasar por un servidor X que recibe eventos y coordina el render. Wayland reduce intermediarios y deja que el compositor controle más directamente el flujo visual. Eso puede traducirse en menos overhead, mejor sincronización y menos tearing en configuraciones modernas, especialmente cuando el compositor está bien afinado.

Ahora bien, no todo es blanco o negro. X11 sigue teniendo ventajas reales en compatibilidad con herramientas antiguas, flujos de trabajo con ciertas utilidades de automatización y casos donde el soporte de hardware o de apps específicas en Wayland todavía no está al nivel que necesitas. Si tu trabajo depende de una app legacy o de una extensión muy específica, no conviene migrar solo por moda.

Lo que suele sentirse en escritorio

En uso de escritorio, la diferencia más clara aparece en la consistencia. Wayland puede dar una sensación más limpia cuando arrastras ventanas, haces scroll rápido o usas múltiples monitores con diferentes tasas de refresco. X11 puede sentirse perfectamente bien, pero en algunos setups se nota más el tearing o una respuesta menos uniforme.

También hay un detalle que mucha gente pasa por alto: el comportamiento del cursor. En Wayland, el cursor y la composición suelen estar más integrados con el compositor, lo que ayuda a evitar ciertas inconsistencias. En X11, dependiendo del driver y del entorno, puedes ver más variación en cómo se actualiza la pantalla respecto del movimiento del puntero.

Si tú trabajas muchas horas con edición de texto, navegador, terminal y videollamadas, la latencia no es solo para gamers. Una interfaz que responde con menos jitter cansa menos la vista y hace que el uso diario se sienta más fluido, aunque no puedas ponerle un número exacto en cada interacción.

VRR: el factor que cambia la comparación

VRR, o Variable Refresh Rate, ajusta el refresco del monitor al ritmo de los frames que entrega la GPU. En teoría, eso reduce tearing y mejora la suavidad. En la práctica, también cambia cómo percibes la latencia, porque el sistema ya no está atado a un refresco fijo tan rígido.

Aquí es donde la comparación entre X11 y Wayland se vuelve más interesante. Con VRR bien implementado, Wayland suele aprovechar mejor la relación entre compositor y monitor, siempre que tu entorno lo soporte correctamente. En X11, el soporte de VRR ha existido, pero la integración depende más del stack, del driver y del entorno de escritorio.

Si juegas a 90, 120 o 144 Hz, la diferencia entre una presentación estable y una con microtirones puede ser más visible que la diferencia entre 2 o 3 ms en promedio. Por eso, en un monitor de alta tasa, la estabilidad del frame pacing pesa mucho. No te sirve de mucho un promedio bonito si cada tanto el compositor mete una pausa rara.

Cuándo VRR sí te conviene

VRR te conviene sobre todo si tu GPU no sostiene siempre el refresco nativo del monitor. Por ejemplo, si un juego oscila entre 85 y 120 FPS en un panel de 144 Hz, VRR puede suavizar esa variación. También ayuda en escritorio cuando abres videos, haces scroll o mueves ventanas pesadas y quieres evitar saltos visibles.

Pero VRR no arregla todo. Si el cuello de botella está en la app, en el driver o en la propia carga de CPU, el beneficio baja. Además, algunos compositores y configuraciones pueden desactivar o limitar VRR en ciertos modos, así que conviene verificar tu entorno antes de asumir que está activo.

DXVK y gaming: dónde entra en la discusión

DXVK traduce llamadas de Direct3D 9, 10 y 11 a Vulkan. Eso significa que, en juegos de Windows ejecutados en Linux con Proton o Wine, el camino de render cambia bastante. Y cuando cambia el render, también cambia la latencia que tú percibes, porque la cola de frames y la sincronización con el compositor ya no se comportan igual que en una app nativa.

La relación con X11 y Wayland es directa: el compositor y el backend gráfico influyen en cómo se presentan esos frames traducidos. Si el juego usa DXVK y tu sistema está bien configurado, Wayland puede ofrecer una presentación más consistente en algunos casos. Pero si el juego, el driver o el compositor no están finos, X11 puede seguir siendo más predecible para ciertos títulos.

Según la documentación de DXVK, el objetivo es una traducción eficiente sobre Vulkan, no un milagro de latencia. Puedes revisar su repositorio y documentación oficial en DXVK on GitHub. Lo que importa para ti es que el rendimiento real depende del juego, del driver y del compositor, no solo del protocolo de escritorio.

Escenarios reales de juego

Si juegas títulos competitivos, la prioridad suele ser minimizar la cola de frames y evitar cualquier capa extra que agregue retraso. En ese caso, un setup bien afinado con Wayland, VRR y drivers maduros puede darte una experiencia muy buena. Pero si tu juego favorito tiene bugs visuales o problemas con overlays, X11 puede seguir siendo la opción más estable.

En juegos single-player, la conversación cambia un poco. Ahí la latencia sigue importando, pero normalmente priorizas consistencia visual y estabilidad. Si DXVK te da buenos FPS y el compositor no introduce stutter, vas a sentir el sistema más cómodo aunque no estés obsesionado con cada milisegundo.

Un punto útil: si el juego tiene opción de fullscreen exclusivo, borderless o frame limiter, prueba combinaciones. A veces la diferencia entre un entorno que se siente “pesado” y uno que se siente ágil está más en la configuración del juego que en el protocolo gráfico.

Cómo medir sin caer en autoengaño

Medir latencia en Linux no es trivial porque hay muchas variables. Si comparas X11 y Wayland sin controlar monitor, tasa de refresco, driver, compositor y tipo de app, puedes sacar conclusiones erróneas. Lo ideal es probar el mismo hardware, la misma sesión, la misma carga y varias repeticiones.

Para medir con algo de rigor, puedes usar herramientas de captura de frames, logs del compositor o pruebas repetibles con cursor y entrada. No necesitas montar un laboratorio para sacar conclusiones útiles, pero sí evitar la típica prueba de “lo sentí más rápido” después de cambiar tres cosas al mismo tiempo.

Una metodología simple te sirve mucho más que una cifra aislada. Por ejemplo:

1. Usa el mismo monitor y fija su tasa de refresco, por ejemplo 60 Hz o 144 Hz.
2. Prueba la misma app en X11 y en Wayland, sin cambiar drivers.
3. Repite la prueba con VRR apagado y luego encendido.
4. Si juegas, usa el mismo título, la misma escena y la misma resolución.
5. Registra al menos 3 a 5 corridas por configuración.

Tabla de lectura rápida de escenarios

Si quieres una referencia técnica adicional sobre sincronización y presentación, la documentación de Vulkan ayuda a entender por qué DXVK y el compositor interactúan tanto con la latencia final. No hace falta que leas todo para usar Linux, pero sí entender que la cadena gráfica moderna ya no depende de un único componente.

Qué decisión tomar según tu caso

Si tu prioridad es escritorio moderno, monitores con alta tasa de refresco y una experiencia visual más consistente, Wayland ya merece una prueba seria. No hace falta esperar a que todo sea perfecto para usarlo, sobre todo si tu distro y tu entorno de escritorio ya lo soportan bien. En muchos equipos actuales, la diferencia práctica frente a X11 ya no es teórica.

Si dependes de una app específica, automatización antigua o un juego que se porta mal en Wayland, no fuerces el cambio. X11 sigue siendo útil y, en algunos contextos, más estable. La decisión correcta no es “Wayland siempre” ni “X11 siempre”, sino el stack que te dé menos fricción en tu hardware y tu carga real.

Para productividad, la recomendación es más simple de lo que parece: si tu sesión Wayland está libre de bugs y tus herramientas funcionan, úsala. Si notas problemas con screen sharing, overlays o apps antiguas, vuelve a X11 y compara de nuevo dentro de unos meses. El ecosistema cambia rápido y lo que hoy falla, mañana puede estar resuelto.

Tabla resumen

Al final, la pregunta no es si X11 o Wayland ganan en abstracto. La pregunta real es cuál te da menos latencia visible, menos stutter y menos problemas en tu escenario. Si mides bien, puedes salir de la discusión de opiniones y tomar una decisión basada en tu equipo, tu monitor y tu forma de usar Linux.