- Em um ambiente Fedora Workstation 41·GNOME 47, foi feita uma comparação entre Wayland e X11 filmando a latência do cursor em câmera lenta a 240 FPS
- O método consistiu em contar, a partir do quadro em que o mouse começa a se mover até o quadro em que o cursor aparece na nova posição, registrando a latência em quadros em 16 medições no Wayland e 16 no X11
- No GNOME X11, a média medida foi de 4 quadros·16,7ms·2,4 atualizações de tela, enquanto no GNOME Wayland foi de 5,5625 quadros·23,2ms·3,3 atualizações de tela
- Nesse sistema, o Wayland mostrou em média cerca de 6,5ms a mais de latência do cursor do que o X11, com uma diferença próxima de quase 1 atualização completa da tela
- O resultado mostra apenas a diferença de latência do cursor na combinação GNOME/AMD, e não é evidência de que a latência de entrada do Wayland seja maior em jogos ou em aplicações gráficas em geral
Por que medir isso
- A partir de Wayland Cursor Lag: Just give me a break already..., que aborda a insatisfação de um usuário Linux com a latência de entrada no Wayland, foi realizado um experimento para obter números concretos em vez de percepção subjetiva
- Embora o Wayland estivesse sendo usado com satisfação no geral, a impressão de que havia mais latência do cursor do que no X11 foi o ponto de partida do experimento
- Considerou-se que a câmera de celular a 90 FPS usada no texto anterior não era suficiente para avaliar uma diferença do nível de uma atualização de tela, então foi usado o modo de gravação a 240 FPS
Método de medição
- Com a câmera do celular, foram filmados ao mesmo tempo a tela, a mesa, o cursor do mouse, o mouse e a mão, enquanto o mouse era repetidamente impulsionado com o dedo
- Depois de 16 gravações na sessão GNOME Wayland, foi feito login na sessão GNOME X11 e repetido o mesmo procedimento outras 16 vezes
- Os vídeos gravados foram convertidos em quadros JPEG com o comando
ffmpeg -i <input file> %04d.jpg - A latência em quadros foi contada com base nos seguintes critérios
- a contagem começa no primeiro quadro em que é possível ver o mouse se movendo
- vai até o primeiro quadro em que o cursor é visto se movendo claramente para a nova posição
- os quadros inicial e final são ambos incluídos
- por exemplo, se o mouse se move no quadro 1045 e o cursor se move no quadro 1047, isso é registrado como uma latência de 3 quadros
Ambiente de teste
- O hardware e o software do experimento foram os seguintes
- distribuição: Fedora Workstation 41
- versão do GNOME: 47
- CPU: AMD Ryzen 9 5950X
- GPU: AMD Radeon RX 7900XT
- monitor: Gigabyte M32U, 4K IPS, 144,99Hz, sem escalonamento de DPI
- mouse: Logitech G502 Lightspeed
- câmera: iPhone 15 Pro, câmera lenta a 240 FPS
Limitações da medição
- Mesmo a 240 FPS, em uma tela de 144Hz há menos de 2 quadros da câmera por atualização da tela, o que gera variação aleatória
- Como os pixels não mudam instantaneamente, existem quadros ambíguos em que o cursor começa a aparecer muito fracamente na nova posição
- Mesmo que o cursor ainda não estivesse completamente brilhante, se ele já pudesse ser visto claramente na nova posição isso era contado como movimento do cursor
- O vídeo do iPhone continha alguns quadros duplicados, e a causa é desconhecida
- os quadros duplicados foram tratados como quadros normais, assumindo-se que um intervalo de um quadro havia se passado
- Esses fatores introduzem incerteza nos resultados, mas considera-se que afetam Wayland e X11 da mesma forma e que, com dados suficientes, tendem a se compensar na média
- Como não foram testados compositores Wayland além do GNOME nem drivers de GPU além de AMD, os resultados podem ser diferentes em outras combinações
Resultados da medição
- As 16 medições do GNOME X11 foram
5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4quadros- média: 4 quadros
- tempo de latência: 16,7ms
- atualizações de tela: 2,4
- As 16 medições do GNOME Wayland foram
6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6quadros- média: 5,5625 quadros
- tempo de latência: 23,2ms
- atualizações de tela: 3,3
- Nesse sistema, o Wayland mostrou em média cerca de 6,5ms a mais de latência do cursor do que o X11
- Não há pretensão de fazer uma análise estatística rigorosa da significância, mas pelos valores medidos parece haver uma diferença clara e consistente
- A diferença fica próxima de 1 atualização de tela, embora não seja possível dizer se isso é coincidência
Conclusão e escopo da interpretação
- Este experimento mostra que, em um hardware específico, existe uma diferença de latência de entrada entre X11 e Wayland, e que ela pode ser grande o suficiente para alguns usuários perceberem
- Para entender com mais clareza o alcance e o tamanho do problema, seriam necessários testes adicionais em uma variedade maior de hardwares e taxas de atualização de tela
- O tamanho da diferença pode variar conforme fatores como o compositor em uso e a taxa de atualização da tela
- Como experimentos adicionais exigem muito tempo, é provável que não sejam realizados diretamente
- Este teste não mostra que o Wayland tenha, de forma geral, latência de entrada maior que o X11
- em especial, não é evidência de que a latência de entrada do Wayland seja maior em jogos
- a latência adicional pode ser exclusiva do cursor
- entende-se que o cursor é tratado de forma muito diferente das aplicações gráficas comuns
- seria necessário um teste separado para verificar se o Wayland tem latência de entrada maior que o X11 em jogos
1 comentários
Opiniões do Hacker News
Excelente abordagem. Parece que as pessoas muitas vezes recorrem a suposições para coisas que poderiam verificar experimentalmente. Desde que aprendi o método científico, sempre me senti atraído pela ideia de “vamos projetar um experimento”
Não sei por que há latência adicional no Wayland, mas, como alguém que fazia parte da comunidade de computadores na época em que o X11 surgiu, posso dizer que, desde o começo, as reclamações sobre atraso na tela nunca pararam. Valia tanto para a resposta do cursor quanto para a rolagem no xterm
Quando as “workstations” apareceram, algumas tinham hardware de exibição separado só para o mouse, justamente para reduzir a latência de renderizar o mouse dentro do frame. Havia também a infame patente do XOR: https://patents.google.com/patent/US4197590
Graças a essas reclamações, o caminho de código que vai da entrada de teclado/mouse até o reflexo na tela continuou sendo revisado em busca de formas de torná-lo “mais rápido, com menor latência”. O Wayland é relativamente “novo” em comparação com o X11, então não foi validado por tanto tempo, mas espero que as pessoas sigam corrigindo isso
Um plano pode ser atualizado ou reposicionado sem redesenhar o restante da tela. A imagem normal da tela fica no plano base, e mover o cursor é mais parecido com fazer commit da nova posição do plano
A latência de entrada adicionada pelo servidor Wayland usado aqui, o GNOME Mutter, provavelmente é uma questão de estratégia de amostragem de entrada e de temporização de commits. Cada servidor tem estratégias e prioridades diferentes, o que gera prós e contras
Wayland é um protocolo e não participa do processo normal de posicionamento do cursor. Portanto, esse problema está inteiramente no domínio da implementação interna e da otimização do servidor de exibição. No nível do protocolo, o que acontece é basicamente permitir que o cliente defina a imagem do cursor e informar ao cliente a posição do cursor
Pelo que me lembro, a situação começou a piorar quando o glamour apareceu no Xorg. Quando o caminho de renderização do cursor deixou de ser seguro para executar dentro de um handler de sinal — algo inevitável quando é baseado em OpenGL —, a latência piorou
Antigamente, mesmo quando uma máquina Linux estava thrashing, o ponteiro do mouse continuava respondendo, e isso era um indicador confiável para saber se o kernel tinha travado ou não. Se o ponteiro não respondesse cedo o bastante, era o caso de ativar unmask irq com hdparm em hosts IDE/PATA. No XFree86, um ponteiro sem resposta era um sinal muito útil de que algo estava errado ou mal configurado; sinto falta daqueles tempos
Eu entendo reclamar de software gratuito, mas isso vem sendo uma migração forçada para algo pior há tempo demais. A adoção do Wayland deveria ter acontecido com a premissa de que ele fosse quase universalmente superior em todos os requisitos de entrada e exibição
Intel, AMD, Nvidia e fabricantes Arm deveriam se empenhar totalmente, em consórcio, por um Linux desktop utilizável. Governos também. Um desktop Linux seguro é de fato possível e é o caminho mais rápido para demonstrar CPU, recursos 3D e hardware avançado de vetores/computação
O Wayland acabou aumentando ainda mais o atraso do desktop Linux ao surgir numa época em que o Windows tentava se arruinar com uma UI de tiles horrível e a Apple se recusava obstinadamente a ganhar a capitalização de mercado adicional que poderia ter obtido lançando o macOS para x86 comum
A parte que exige cuidado é ao arrastar uma janela ou ícone, quando a latência da swapchain começa a aparecer. Alguns compositores de janelas consideram que a alta taxa de atualização torna a latência menos perceptível e já não se preocupam mais com isso; o macOS é um exemplo, e o Windows parece alternar para um cursor de mouse por software durante o arrasto
Apps em tela cheia deveriam passar por um caminho rápido, seja atravessando o compositor ou contornando-o
Para quem usa ffmpeg nesse tipo de análise quadro a quadro,
ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.pngpermite obter o tempo de exibição de cada frame do vídeo. É mais preciso do que simplesmente despejar os frames e calcular os timestampsNo navegador, também dá para fazer algo parecido reproduzindo o vídeo e usando
requestVideoFrameCallback(). Porém, se o computador não conseguir decodificar todos os frames rápido o suficiente, talvez seja necessário reduzir.playbackRateO fato de, em uma tela de 144 Hz, o Wayland ser em média cerca de 6,5 ms mais lento que o X11, e essa diferença ser quase igual a uma atualização de tela, talvez não seja coincidência. Se a latência for quase 1/144 de segundo, em um monitor comum de 60 Hz ela também pode virar 1/60 de segundo. Sem treino, é difícil perceber conscientemente, mas a maioria das pessoas consegue “sentir”, mesmo sem explicar
Claro que, para muitos usuários, a taxa de polling de 125 Hz do mouse também é um fator de confusão, mas neste caso foi usado um mouse de 1 kHz
Uma diferença de 7 ms não é ruim, mas uma diferença de 16,6 ms começa a ficar bem grande. Pessoalmente, acho que os computadores deveriam tentar mirar em 1,6 frame de latência: meio frame de fase aleatória, um frame, e um pouco de tempo de processamento
Os resultados vão variar conforme o compositor, a GPU e as configurações. No X11, como há praticamente uma única implementação de servidor X usada pelos sistemas desktop Linux, essas diferenças são menores
Ainda pode haver o problema de muitas combinações de compositor/GPU não conseguirem obter um plano de cursor por hardware, e, se for esse o caso, essas diferenças de latência podem perfeitamente aparecer
Descobri hoje que o Wayland já tem 16 anos. Daqui a alguns anos, ele terá a mesma idade que o X tinha quando o Wayland surgiu, mas ainda parece ser visto como mediano ou inferior ao X
$very_specific_feature” ou que “fico triste porque o driver proprietário do fabricante da minha placa de vídeo não foi testado o suficiente no Wayland”Cerca de 99,999% dessas reclamações vêm de pessoas que 1) não fazem o trabalho elas mesmas, 2) não têm interesse ou capacidade para fazê-lo e 3) não entendem ou não admitem que os desenvolvedores do Wayland e do X são, em grande parte, as mesmas pessoas, e que elas não querem mais trabalhar no X11
Não tenho nenhum interesse especial nessa discussão, mas cansei de ver gente usando software que outros deram de graça e reclamando do Wayland. Se houvesse tantas reclamações sobre o Wayland assim, a esta altura poderiam ter se organizado para manter e melhorar o X e, se as reclamações e teorias estivessem certas, deixar o Wayland para trás
Curiosamente, embora o X seja open source e possa ser forkado à vontade — e apesar do exemplo do X.org ter surgido a partir do XFree86 — seus defensores o deixam juntando poeira e não fazem nada pela manutenção
Eu ficaria bastante interessado se aparecesse um resultado como “o Wayland não é tão bom quanto o X, então criamos um fork modernizado do X que qualquer um pode usar”
Ou seja, o Wayland tem apenas cerca de 66% da idade que o X tinha quando o Wayland surgiu; para chegar à mesma idade, ainda precisaria de mais 50% do tempo de vida atual do Wayland
Estou usando Wayland no Plasma 6 agora e funciona bem o suficiente, mas não tenho requisitos especiais, então não sei, por exemplo, quão bem leitores de tela funcionam
Nesse ponto, espero que a stack de front-end dos navegadores tenha engolido completamente o desktop. De qualquer forma, nunca foi como se muitos aplicativos desktop novos estivessem chegando ao Linux
Não é surpresa que a maioria das tentativas de reescrever uma solução que funciona sob o argumento de ser “mais moderna, mais fácil de manter e preparada para o futuro” não acabe assim. Em geral, fica mais lenta, aumenta a latência, e apenas hardware mais rápido passa a sustentá-la — não é que o software tenha ficado mais rápido
Parece que, a cada 20 anos, uma nova geração fica mais fraca ao se apoiar de forma mimada nas abstrações que a geração anterior criou fazendo o trabalho difícil. Depois de umas três gerações de desenvolvedores de software, o que sobrou são basicamente chamadores de bibliotecas/frameworks, e quase ninguém entende desempenho e otimização de verdade
O Wayland ainda carece de alguns recursos em comparação com o X11, mas estou disposto a aceitar esse compromisso por causa das outras vantagens
Vários compositores Wayland têm grandes problemas com teclado, mouse e outros dispositivos de entrada. Isso acontece porque a especificação do Wayland e a implementação de referência decidiram não dar suporte a essas coisas. Então cada compositor Wayland escolhe uma solução diferente
As escolhas comuns são libei e libinput, mas muitas vezes a entrada “avançada” de mouse/teclado nem é suportada. O weston é um exemplo disso. Não há como saber se um software Linux específico vai funcionar em um ambiente Wayland específico, e a fragmentação é grave
No X, há uma referência X11 forte que implementa praticamente tudo, então você pode ter certeza de que, se funciona em um lugar, funciona em outro
Mesmo depois de 12 anos, ainda não há nenhum compositor Wayland que ofereça suporte a leitores de tela para pessoas cegas. É coisa de brinquedo
Então não é bom para jogos, não é bom para trabalho gráfico profissional e não é bom para pessoas com baixa visão. No fim das contas, quer dizer que, de modo geral, não é bom para usuários que sejam minimamente diferentes de quem o criou
Ainda assim, com sorte, talvez tenha reduzido o tearing de tela que eu nunca percebi
Um dos resultados legais disso é ver pessoas adicionando fluxos de trabalho de acessibilidade em cima desse ecossistema. Uma pessoa controla todo o desktop por meio de um gerenciador de janelas em mosaico usando controle por voz: https://youtu.be/fiPJLmhnnXM
Quando a GPU está sob carga pesada, por exemplo ao executar uma inferência do Stable Diffusion, surgem grandes picos de latência. Não fiz um teste A/B com o X11, mas não me lembro de isso acontecer antes
Um atraso adicional de um frame já não é bom, mas os picos de latência ocasionais são realmente irritantes
A latência na entrada do cursor é um incômodo que vai corroendo continuamente a satisfação com um aplicativo ou sistema operacional
Atraso no cursor de texto da IDE? Inaceitável
Atraso no cursor de texto do shell? Inaceitável
Atraso no cursor do mouse na GUI? Inaceitável
Tudo isso é motivo para reprovação imediata
Até o System 1, que rodava há mais de 40 anos em hardware quase infinitamente mais fraco, colocava a responsividade do cursor como prioridade máxima e superava todos os concorrentes. A base do SO e da UI atuais é 100% diferente, mas essa prioridade continua mantida
Recentemente passei por uma lentidão extrema do mouse com a combinação X11 e NVidia no KDE/Plasma 6. Notei que a lentidão era especialmente forte sobre as abas do navegador
Para quem tiver o mesmo problema, deixo registrado: a solução foi desativar o OpenGL flipping. Não faço a menor ideia do que o OpenGL flipping faz, mas desativá-lo no nvidia-settings e em
/etc/X11/xorg.confresolveu o problemaSeria bom se alguém explicasse por quê, ou por que isso não é o padrão
Ótimo trabalho. Talvez valha a pena repetir o experimento colocando o monitor em uma taxa de atualização bem baixa, por exemplo 30 Hz
Se o Wayland for sempre um frame mais lento que o X11, isso deve ficar muito mais fácil de observar
Tenho uma reclamação pessoal um pouco diferente. Quando comecei a usar Linux, o desktop usava composição por software. Provavelmente a CPU desenhava a UI na RAM e depois fazia um blit para o framebuffer da GPU, e acho que esse era o método usado havia muito tempo
Com os compositores, incluindo o X11 Composite, e depois com a popularização dos renderizadores por GPU, a latência ficou horrível, literalmente na casa de centenas de ms. Era estranho, porque eu cresci jogando jogos de DOS e não havia esse problema
Com o tempo isso melhorou, mas não sei bem se voltamos à era de ouro da renderização por CPU