- En un entorno con Fedora Workstation 41 y GNOME 47, se comparó la latencia del cursor entre Wayland y X11 grabándola en cámara lenta a 240 FPS
- Midiendo desde el fotograma en que el mouse empieza a moverse hasta el fotograma en que el cursor aparece en su nueva posición, se registró la latencia en fotogramas en 16 pruebas de Wayland y 16 de X11
- En GNOME X11 se midió un promedio de 4 fotogramas, 16.7 ms y 2.4 refrescos de pantalla, mientras que en GNOME Wayland fue de 5.5625 fotogramas, 23.2 ms y 3.3 refrescos de pantalla
- En este sistema, Wayland mostró en promedio alrededor de 6.5 ms más de latencia del cursor que X11, y la diferencia fue casi equivalente a 1 refresco de pantalla
- Los resultados solo muestran la diferencia de latencia del cursor en una combinación GNOME/AMD, y no son prueba de que Wayland tenga mayor latencia de entrada en juegos o aplicaciones gráficas generales
Por qué se hizo la medición
- A partir de Wayland Cursor Lag: Just give me a break already..., donde un usuario de Linux se quejaba de la latencia de entrada en Wayland, se realizó un experimento para obtener cifras concretas en lugar de depender de sensaciones subjetivas
- Aunque el autor usa Wayland con satisfacción en general, la impresión de que había más latencia del cursor que en X11 fue el punto de partida del experimento
- Se consideró que la cámara de 90 FPS de la publicación anterior no era suficiente para distinguir diferencias del orden de un refresco de pantalla, así que se usó el modo de grabación a 240 FPS
Método de medición
- Con la cámara del teléfono se grabó al mismo tiempo la pantalla, el escritorio, el cursor del mouse, el mouse y la mano, mientras se impulsaba repetidamente el mouse con un dedo
- Después de grabar 16 veces en una sesión de GNOME Wayland, se inició sesión en GNOME X11 y se repitió el mismo procedimiento otras 16 veces
- Los videos grabados se convirtieron en fotogramas JPEG con el comando
ffmpeg -i <input file> %04d.jpg - La latencia en fotogramas se contó con los siguientes criterios
- El conteo empieza en el primer fotograma en que se ve que el mouse se mueve
- Termina en el primer fotograma en que se ve claramente que el cursor se movió a una nueva posición
- Se incluyen tanto el fotograma inicial como el final
- Por ejemplo, si el mouse se mueve en el fotograma 1045 y el cursor se mueve en el 1047, se registra una latencia de 3 fotogramas
Entorno de prueba
- El hardware y software del experimento fueron los siguientes
- Distribución: Fedora Workstation 41
- Versión de GNOME: 47
- CPU: AMD Ryzen 9 5950X
- GPU: AMD Radeon RX 7900XT
- Monitor: Gigabyte M32U, 4K IPS, 144.99 Hz, sin escalado DPI
- Mouse: Logitech G502 Lightspeed
- Cámara: iPhone 15 Pro, cámara lenta a 240 FPS
Limitaciones de la medición
- Incluso a 240 FPS, en una pantalla de 144 Hz hay menos de 2 fotogramas de cámara por cada refresco, lo que introduce variación aleatoria
- Como los píxeles no cambian de inmediato, existen fotogramas ambiguos en los que el cursor apenas empieza a verse muy tenuemente en su nueva posición
- Aunque el cursor no estuviera completamente brillante, se contó como movimiento si ya se veía claramente en la nueva posición
- El video del iPhone incluía algunos fotogramas duplicados, y no se sabe la causa
- Los fotogramas duplicados se trataron como si hubiera transcurrido el tiempo de un fotograma normal
- Se considera que estos factores introducen incertidumbre, pero afectan por igual a Wayland y X11, por lo que deberían promediarse con suficientes datos
- No se probaron otros compositores Wayland aparte de GNOME ni controladores de GPU distintos de AMD, así que en otras combinaciones los resultados podrían variar
Resultados de la medición
- Las 16 mediciones de GNOME X11 fueron
5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4fotogramas- Promedio: 4 fotogramas
- Latencia: 16.7 ms
- Refrescos de pantalla: 2.4
- Las 16 mediciones de GNOME Wayland fueron
6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6fotogramas- Promedio: 5.5625 fotogramas
- Latencia: 23.2 ms
- Refrescos de pantalla: 3.3
- En este sistema, Wayland mostró en promedio alrededor de 6.5 ms más de latencia del cursor que X11
- Aunque el autor no afirma tener la experiencia necesaria para analizar si la diferencia es estadísticamente significativa, en los valores medidos parece haber una diferencia clara y consistente
- La diferencia está cerca de equivaler a 1 refresco de pantalla, aunque no se sabe si eso fue casualidad
Conclusión y alcance de la interpretación
- Este experimento muestra que en cierto hardware existe una diferencia de latencia de entrada entre X11 y Wayland, y que podría ser lo bastante grande como para que algunos usuarios la noten
- Para entender con claridad el alcance y magnitud del problema, hacen falta más pruebas en hardware más diverso y con distintas tasas de refresco
- El tamaño de la diferencia puede variar según factores como el compositor usado y la frecuencia de actualización de la pantalla
- Es poco probable que el autor haga más experimentos por cuenta propia, ya que requieren mucho tiempo
- Esta prueba no demuestra que Wayland tenga una latencia de entrada general más alta que X11
- En particular, no es evidencia de que Wayland tenga más latencia de entrada en juegos
- La latencia adicional podría ser solo del cursor
- Según el entendimiento del autor, el cursor se procesa de manera muy distinta a una aplicación gráfica común
- Para saber si Wayland tiene más latencia de entrada que X11 en juegos, harían falta pruebas aparte
1 comentarios
Opiniones de Hacker News
Excelente enfoque. Parece que la gente demasiado seguido reemplaza con conjeturas cosas que podría comprobar experimentalmente. Desde que aprendí el método científico, siempre me atrae la idea de “diseñemos un experimento”.
No sé por qué Wayland introduce latencia adicional, pero como alguien que estuvo en la comunidad de computación cuando X11 apareció por primera vez, puedo decir que desde los primeros días hubo quejas constantes sobre la latencia de pantalla. Lo mismo daba si era la respuesta del cursor o el desplazamiento en xterm.
Cuando aparecieron las “workstations”, a veces tenían hardware de visualización separado solo para el mouse, pensado para reducir la latencia de renderizar el mouse dentro del frame. También estaba la infame patente de XOR: https://patents.google.com/patent/US4197590
Gracias a estas quejas, la ruta de código que va desde la entrada de teclado/mouse hasta su reflejo en pantalla siguió revisándose para encontrar formas de hacerla “más rápida, con menor latencia”. Wayland es relativamente “nuevo” frente a X11, así que no ha sido validado durante tanto tiempo, pero espero que la gente lo vaya corrigiendo.
Los planos pueden actualizarse o cambiarse de posición sin volver a dibujar el resto de la pantalla. La imagen normal de la pantalla está en el plano principal, y mover el cursor se parece más a confirmar una nueva posición de ese plano.
La latencia de entrada adicional que añade GNOME Mutter, el servidor Wayland usado aquí, probablemente sea un problema de estrategia de muestreo de entrada y temporización de commits. Cada servidor tiene estrategias y prioridades distintas, con sus ventajas y desventajas.
Wayland es un protocolo, así que no interviene en el proceso normal de posicionamiento del cursor. Por lo tanto, este problema pertenece por completo al ámbito de implementación interna y optimización del servidor de visualización. A nivel de protocolo, lo que ocurre es básicamente permitir que el cliente configure la imagen del cursor y avisarle al cliente la posición del cursor.
Según recuerdo, la situación empezó a empeorar en Xorg cuando apareció glamour. Cuando la ruta de renderizado del cursor dejó de ser segura para ejecutarse desde un manejador de señales —algo inevitable si está basada en OpenGL—, la latencia empeoró.
Antes, incluso si una máquina Linux estaba haciendo thrashing, el puntero del mouse seguía respondiendo, y era un indicador confiable para saber si el kernel se había colgado o no. Si el puntero no respondía lo suficientemente pronto, en hosts IDE/PATA había que activar unmask irq con hdparm. En XFree86, un puntero que no respondía era una señal muy útil de que algo estaba mal o mal configurado; extraño esos tiempos.
Entiendo quejarse del software gratis, pero esto lleva demasiado tiempo siendo una migración forzada hacia algo peor. La adopción de Wayland debería haberse hecho sobre la premisa de que era casi universalmente superior para todos los requisitos de entrada y visualización.
Intel, AMD, Nvidia y los fabricantes de Arm deberían hacer un esfuerzo total en consorcio para lograr un Linux de escritorio usable. Los gobiernos también. Porque un escritorio Linux seguro es realmente posible, y es el camino más rápido para mostrar las capacidades de CPU, 3D y hardware avanzado de vectores/cómputo.
Wayland apareció en una época en la que Windows intentaba arruinarse con una interfaz de mosaicos horrible y Apple se negaba obstinadamente a capturar la capitalización de mercado adicional que habría obtenido si lanzaba macOS para x86 genérico; y terminó aumentando aún más la demora del escritorio Linux.
Donde se vuelve delicado es al arrastrar una ventana o un ícono: ahí empieza a notarse la latencia de la swapchain. Algunos compositores de ventanas ya no se preocupan porque consideran que las altas tasas de refresco hacen que la latencia sea menos visible; macOS es un ejemplo, y Windows parece cambiar a un cursor de mouse por software durante el arrastre.
Las apps en pantalla completa deberían pasar por una ruta rápida que atraviese o evite el compositor.
Para quienes usen ffmpeg en este tipo de análisis cuadro por cuadro, con
ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.pngse puede obtener el tiempo de presentación de cada frame del video. Es más preciso que simplemente volcar los frames y calcular las marcas de tiempo.En un navegador web también se puede hacer algo similar reproduciendo el video y usando
requestVideoFrameCallback(). Aunque, si la computadora no puede decodificar todos los frames lo suficientemente rápido, quizá haya que bajar.playbackRate.Que en una pantalla de 144 Hz Wayland sea en promedio unos 6.5 ms más lento que X11, y que esa diferencia sea casi igual a una actualización de pantalla, puede no ser casualidad. Si la latencia es casi 1/144 de segundo, en un monitor común de 60 Hz podría convertirse en 1/60 de segundo. Sin entrenamiento es difícil notarlo conscientemente, pero la mayoría puede “sentirlo” aunque no pueda explicarlo.
Por supuesto, para muchos usuarios la tasa de sondeo del mouse de 125 Hz también es un factor de confusión, pero en este caso se usó un mouse de 1 KHz.
Una diferencia de 7 ms no está mal, pero una de 16.6 ms ya empieza a ser bastante grande. Personalmente creo que las computadoras deberían esforzarse por apuntar a una latencia de 1.6 frames: medio frame de fase aleatoria, un frame y algo de tiempo de procesamiento.
Los resultados variarán según el compositor, la GPU y la configuración. En X11, prácticamente hay una sola implementación del servidor X que usan los sistemas de escritorio Linux, así que esas diferencias son menores.
Todavía puede haber un problema en muchas combinaciones de compositor/GPU donde no se obtiene el plano de cursor por hardware, y si es así, esas diferencias de latencia pueden aparecer perfectamente.
Hoy me enteré de que Wayland ya tiene 16 años. En unos años tendrá la misma edad que tenía X cuando salió Wayland, pero parece que todavía se lo considera mediocre o peor que X.
$very_specific_feature” o que “me entristece que el driver propietario del fabricante de mi tarjeta gráfica no esté lo bastante probado en Wayland”.Aproximadamente el 99.999% de esas quejas viene de personas que 1) no hacen el trabajo ellas mismas, 2) no tienen interés ni capacidad para hacerlo, y 3) no entienden o no aceptan que los desarrolladores de Wayland y X son, en su mayoría, las mismas personas, y que ya no quieren trabajar en X11.
No tengo ningún interés particular en esta discusión, pero estoy cansado de ver a gente quejarse de Wayland mientras usa software que otros le dieron gratis. Si hubiera tantas quejas sobre Wayland, para estas alturas podrían haberse organizado para mantener y mejorar X y, si sus quejas y teorías fueran correctas, dejar a Wayland atrás.
Curiosamente, aunque X es open source y se puede forkar libremente —con el precedente de X.org saliendo de XFree86—, sus partidarios lo dejan juntando polvo y no hacen nada por mantenerlo.
Me interesaría bastante ver el resultado de “Wayland no es tan bueno como X, así que hicimos un fork modernizado de X que cualquiera puede usar”.
Es decir, Wayland apenas tiene alrededor del 66% de la edad que tenía X cuando salió Wayland, y para llegar a la misma edad necesita un 50% más de la vida que lleva ahora.
Ahora uso Wayland en Plasma 6 y funciona suficientemente bien, pero no tengo necesidades especiales, así que no sé, por ejemplo, qué tan bien funcionan los lectores de pantalla.
Para entonces, espero que el stack de frontend de los navegadores se haya comido por completo el escritorio. De todos modos, tampoco es que estuvieran saliendo muchas apps nuevas de escritorio para Linux.
No sorprende que la mayoría de los intentos de reescribir una solución que funciona porque supuestamente será “más moderna, más fácil de mantener y preparada para el futuro” no terminen siendo eso. Por lo general se vuelve más lenta, aumenta la latencia, y solo la sostiene hardware más rápido; no es que el software se haya vuelto más rápido.
Siento que cada 20 años una nueva generación se vuelve más débil, apoyándose de forma consentida en las abstracciones que la generación anterior construyó haciendo el trabajo difícil. Después de unas tres generaciones de desarrolladores de software, lo único que queda son invocadores de librerías/frameworks, y casi nadie entiende realmente de rendimiento y optimización.
Wayland todavía carece de algunas funciones frente a X11, pero por sus otras ventajas estoy dispuesto a aceptar ese compromiso.
Varios compositores Wayland tienen grandes problemas con teclados, mouse y otros dispositivos de entrada. Es porque la especificación de Wayland y la implementación de referencia decidieron no soportar esas cosas. Por eso cada compositor Wayland eligió soluciones diferentes.
Las opciones comunes son libei y libinput, pero muchas veces la entrada “avanzada” de mouse/teclado ni siquiera está soportada. weston es un ejemplo. No hay forma de saber si cierto software de Linux funcionará en cierto entorno Wayland, y la fragmentación es grave.
En X hay una referencia X11 fuerte que implementa prácticamente todo, así que si funciona en un lugar, puedes confiar en que funcionará en otros.
Incluso después de 12 años, no hay ni un solo compositor Wayland que soporte lectores de pantalla para personas ciegas. Es algo de juguete.
Así que no es bueno para juegos, no es bueno para trabajo gráfico profesional y no es bueno para personas con baja visión. En definitiva, no es bueno en general para usuarios que sean apenas distintos de quienes lo crearon.
Aun así, con suerte quizá haya reducido el tearing de pantalla que yo nunca llegué a percibir.
Uno de los resultados geniales de esto es ver a gente agregando flujos de trabajo de accesibilidad sobre este ecosistema. Una persona controla todo el escritorio mediante un gestor de ventanas en mosaico usando control por voz: https://youtu.be/fiPJLmhnnXM
Cuando la GPU está bajo mucha carga, por ejemplo al ejecutar inferencias de Stable Diffusion, aparecen grandes picos de latencia. No hice una prueba A/B contra X11, pero no recuerdo que antes pasara esto.
Que se agregue un frame de latencia ya no es ideal, pero esos picos de latencia ocasionales son realmente molestos.
La latencia en la entrada del cursor es una molestia que va erosionando continuamente la satisfacción con una aplicación o un sistema operativo.
¿Latencia en el cursor de texto de un IDE? Inaceptable.
¿Latencia en el cursor de texto de la shell? Inaceptable.
¿Latencia en el cursor del mouse en la GUI? Inaceptable.
Todo eso es motivo de descarte inmediato.
Incluso System 1, que hace más de 40 años corría en hardware casi infinitamente débil, priorizaba la respuesta del cursor por encima de todo y superaba a todos sus competidores. Las bases del OS y la UI actuales son 100% distintas, pero esa prioridad se mantiene.
Hace poco sufrí una lentitud extrema del mouse con la combinación X11 y NVidia en KDE/Plasma 6. Noté que era especialmente grave al pasar sobre las pestañas del navegador.
Lo dejo anotado para quienes tengan el mismo problema: la solución fue desactivar OpenGL flipping. No tengo la menor idea de qué hace OpenGL flipping, pero al desactivarlo en nvidia-settings y en
/etc/X11/xorg.conf, el problema se resolvió.Me gustaría que alguien explicara por qué pasa eso, o por qué esto no es el valor predeterminado.
Excelente trabajo. Parece que valdría la pena repetir el experimento poniendo el monitor en una tasa de refresco muy baja, por ejemplo 30Hz.
Si Wayland siempre es un frame más lento que X11, sería mucho más fácil de observar.
Tengo una queja personal un poco distinta. Cuando empecé a usar Linux, el escritorio usaba composición por software. Probablemente la CPU dibujaba la UI en la RAM y luego hacía un blit al framebuffer de la GPU; entiendo que esa era la forma en que se hacía desde hacía mucho.
Con los compositores, incluido X11 composite, y luego con la popularización de los renderizadores GPU, la latencia se volvió terrible, literalmente del orden de cientos de ms. Me resultaba extraño, porque al crecer jugando juegos de DOS no tenía ese problema.
Con el tiempo mejoró, pero no estoy seguro de que hayamos vuelto a la edad dorada del renderizado por CPU.