- Comparaison de Wayland et X11 dans un environnement Fedora Workstation 41·GNOME 47, en filmant la latence d’entrée du curseur en ralenti à 240 FPS
- La méthode consiste à compter depuis l’image où la souris commence à bouger jusqu’à celle où le curseur apparaît à sa nouvelle position ; la latence en images a été relevée 16 fois sous Wayland et 16 fois sous X11
- GNOME X11 a été mesuré à 4 images en moyenne, 16,7 ms, soit 2,4 rafraîchissements d’écran ; GNOME Wayland à 5,5625 images en moyenne, 23,2 ms, soit 3,3 rafraîchissements d’écran
- Sur ce système, Wayland a montré une latence du curseur supérieure d’environ 6,5 ms en moyenne à celle de X11, une différence proche d’un rafraîchissement d’écran
- Les résultats ne montrent que la différence de latence du curseur avec la combinaison GNOME/AMD, et ne prouvent pas que la latence d’entrée de Wayland soit plus élevée dans les jeux ou les applications graphiques générales
Pourquoi cette mesure
- Un utilisateur Linux a mené cette expérience pour obtenir des chiffres concrets plutôt qu’un ressenti subjectif, à la suite de l’article Wayland Cursor Lag: Just give me a break already... consacré aux plaintes sur la latence d’entrée de Wayland
- Il utilise Wayland avec une satisfaction globale, mais l’impression que la latence du curseur est plus élevée que sous X11 a servi de point de départ à l’expérience
- La caméra de téléphone à 90 FPS de l’article précédent n’étant pas jugée suffisante pour évaluer une différence de l’ordre d’un rafraîchissement d’écran, le mode de capture à 240 FPS a été utilisé
Méthode de mesure
- L’écran, le bureau, le curseur de la souris, la souris et la main ont été filmés ensemble avec la caméra du téléphone, tandis que la souris était poussée à répétition avec un doigt
- 16 séquences ont été filmées dans une session GNOME Wayland, puis 16 autres de la même manière après connexion à une session GNOME X11
- Les vidéos capturées ont été converties en images JPEG avec la commande
ffmpeg -i <input file> %04d.jpg - La latence en images a été comptée selon les critères suivants
- Le comptage commence à la première image où l’on voit la souris bouger
- Il va jusqu’à la première image où l’on voit clairement le curseur bouger à sa nouvelle position
- L’image de départ et l’image d’arrivée sont toutes deux incluses
- Par exemple, si la souris bouge à l’image 1045 et que le curseur bouge à l’image 1047, cela est enregistré comme une latence de 3 images
Environnement de test
- Le matériel et les logiciels utilisés pour l’expérience étaient les suivants
- Distribution : Fedora Workstation 41
- Version de GNOME : 47
- CPU : AMD Ryzen 9 5950X
- GPU : AMD Radeon RX 7900XT
- Moniteur : Gigabyte M32U, 4K IPS, 144,99 Hz, sans mise à l’échelle DPI
- Souris : Logitech G502 Lightspeed
- Caméra : iPhone 15 Pro, ralenti 240 FPS
Limites de la mesure
- Même à 240 FPS, avec un écran 144 Hz, il y a moins de 2 images caméra par rafraîchissement d’écran, ce qui introduit des variations aléatoires
- Les pixels ne basculant pas instantanément, il existe des images ambiguës où le curseur commence à apparaître très faiblement à sa nouvelle position
- Même si le curseur n’est pas encore pleinement lumineux, il est compté comme ayant bougé dès lors qu’il est clairement visible à sa nouvelle position
- Certaines images dupliquées figuraient dans la vidéo de l’iPhone, sans que la cause soit connue
- Les images dupliquées ont été traitées comme des images normales, en considérant qu’un intervalle d’une image s’était écoulé
- Ces facteurs introduisent de l’incertitude dans les résultats, mais ils sont supposés s’appliquer de la même façon à Wayland et à X11 et se moyenner avec suffisamment de données
- Les compositeurs Wayland autres que GNOME et les pilotes GPU autres qu’AMD n’ayant pas été testés, les résultats peuvent différer avec d’autres combinaisons
Résultats des mesures
- Les 16 mesures sous GNOME X11 sont de
5, 4, 3, 4, 5, 4, 6, 5, 1, 4, 4, 4, 3, 4, 4, 4images- Moyenne : 4 images
- Latence : 16,7 ms
- Rafraîchissements d’écran : 2,4
- Les 16 mesures sous GNOME Wayland sont de
6, 5, 6, 5, 5, 6, 6, 4, 8, 6, 5, 5, 5, 6, 5, 6images- Moyenne : 5,5625 images
- Latence : 23,2 ms
- Rafraîchissements d’écran : 3,3
- Sur ce système, Wayland affiche une latence du curseur supérieure d’environ 6,5 ms en moyenne à celle de X11
- L’auteur n’a pas l’expertise nécessaire pour analyser correctement si c’est statistiquement significatif, mais les mesures semblent montrer une différence nette et cohérente
- La différence est proche d’un rafraîchissement d’écran, sans que l’on sache si c’est une coïncidence
Conclusion et portée de l’interprétation
- Cette expérience montre qu’il existe, sur un matériel donné, une différence de latence d’entrée entre X11 et Wayland, et qu’elle peut être assez importante pour être perceptible par certains utilisateurs
- Pour déterminer clairement l’étendue et l’ampleur du problème, des tests supplémentaires sur une plus grande variété de matériels et de fréquences de rafraîchissement seraient nécessaires
- L’ampleur de la différence peut varier selon des facteurs comme le compositeur utilisé et la fréquence de rafraîchissement de l’écran
- Il est peu probable que l’auteur mène lui-même d’autres expériences, car elles demandent beaucoup de temps
- Ce test ne montre pas que Wayland présente globalement une latence d’entrée plus élevée que X11
- En particulier, ce n’est pas une preuve que la latence d’entrée de Wayland soit plus élevée dans les jeux
- Il est possible que la latence supplémentaire soit propre au curseur
- D’après ce que comprend l’auteur, le curseur est traité de façon très différente des applications graphiques ordinaires
- Il faudrait un test séparé pour savoir si Wayland présente une latence d’entrée plus élevée que X11 dans les jeux
1 commentaires
Avis sur Hacker News
Excellente approche. On dirait que les gens remplacent trop souvent par des suppositions des choses qu’ils pourraient vérifier expérimentalement. Depuis que j’ai appris la méthode scientifique, j’ai toujours été attiré par l’idée de « concevoir une expérience »
Je ne sais pas pourquoi Wayland introduit une latence supplémentaire, mais, pour avoir été dans la communauté informatique à l’époque où X11 est apparu, je peux dire que les plaintes concernant la latence d’affichage existent depuis le tout début. Que ce soit pour la réactivité du curseur ou le défilement dans xterm, c’était pareil
À l’époque où les « stations de travail » sont apparues, certaines avaient même un matériel d’affichage séparé uniquement pour la souris, destiné à réduire la latence liée au rendu de la souris dans la trame. Il y avait aussi le tristement célèbre brevet sur le XOR : https://patents.google.com/patent/US4197590
Grâce à ce genre de plaintes, le chemin de code allant des entrées clavier/souris jusqu’à leur reflet à l’écran a constamment été examiné pour trouver des moyens de le rendre « plus rapide, avec moins de latence ». Wayland est relativement « nouveau » par rapport à X11, il n’a donc pas bénéficié d’autant d’années de validation, mais j’espère que les gens continueront à corriger cela
Les plans peuvent être mis à jour ou repositionnés sans redessiner le reste de l’écran. L’image normale de l’écran se trouve dans le plan principal, tandis que déplacer le curseur revient plus ou moins à valider une nouvelle position de plan
La latence d’entrée ajoutée par GNOME Mutter, le serveur Wayland utilisé ici, tient probablement à sa stratégie d’échantillonnage des entrées et de timing des commits. Chaque serveur a ses propres stratégies et priorités, avec leurs avantages et inconvénients
Wayland est un protocole et n’intervient pas dans le processus habituel de positionnement du curseur. Ce problème relève donc entièrement de l’implémentation interne et des optimisations du serveur d’affichage. Au niveau du protocole, il s’agit essentiellement de permettre au client de définir l’image du curseur et de lui communiquer la position du curseur
Dans mon souvenir, les choses ont commencé à se dégrader avec l’arrivée de glamour dans Xorg. Quand le chemin de rendu du curseur n’a plus été sûr à exécuter dans un gestionnaire de signal — ce qui est évidemment le cas avec OpenGL —, la latence s’est aggravée
Avant, même lorsqu’une machine Linux était en plein thrashing, le pointeur de la souris restait réactif, et c’était un indicateur fiable pour savoir si le noyau était bloqué ou non. Si le pointeur ne répondait pas assez tôt, cela signifiait qu’il fallait activer unmask irq avec hdparm sur un hôte IDE/PATA. Dans XFree86, un pointeur non réactif était un signal très utile indiquant que quelque chose n’allait pas ou que la configuration était incorrecte ; cette époque me manque
Je sais bien qu’il s’agit de se plaindre d’un logiciel gratuit, mais cela fait beaucoup trop longtemps qu’on nous force à migrer vers quelque chose de pire. L’adoption de Wayland aurait dû reposer sur le principe qu’il était presque universellement supérieur pour tous les besoins d’entrée et d’affichage
Intel, AMD, Nvidia et les fabricants Arm devraient mettre toutes leurs forces dans un consortium pour produire un Linux desktop vraiment utilisable. Les gouvernements aussi. Un bureau Linux sûr est réellement possible, et c’est la voie la plus rapide pour mettre en valeur les CPU, les capacités 3D et le matériel vectoriel/de calcul avancé
Wayland est arrivé à une époque où Windows essayait de s’autosaboter avec une horrible interface en tuiles, et où Apple refusait obstinément la capitalisation boursière supplémentaire qu’elle aurait pu obtenir en publiant macOS pour le x86 générique ; il a donc fini par accroître encore le retard du desktop Linux
Ce qui demande plus d’astuce, c’est le déplacement d’une fenêtre ou d’une icône : c’est là que la latence de la swapchain commence à se voir. Certains compositeurs de fenêtres considèrent qu’avec les taux de rafraîchissement élevés, la latence se remarque moins et ne s’en préoccupent plus ; macOS en est un exemple, tandis que Windows semble basculer vers un curseur logiciel pendant le glisser-déposer
Les applications plein écran devraient emprunter un chemin rapide qui passe par le compositeur ou le contourne
Pour ce type d’analyse image par image avec ffmpeg,
ffmpeg -skip_frame nokey -i file -vsync 0 -frame_pts true out%d.pngpermet d’obtenir l’instant d’affichage de chaque image de la vidéo. C’est plus précis que de simplement extraire les images et calculer les horodatagesDans un navigateur web, on peut faire quelque chose de similaire en lisant la vidéo et en utilisant
requestVideoFrameCallback(). En revanche, si l’ordinateur ne parvient pas à décoder toutes les images assez vite, il peut être nécessaire de réduire.playbackRateLe fait qu’à 144 Hz, Wayland soit en moyenne environ 6,5 ms plus lent que X11, et que cet écart corresponde presque exactement à un rafraîchissement d’écran, n’est peut-être pas un hasard. Si la latence est d’environ 1/144 s, elle pourrait devenir 1/60 s sur un moniteur 60 Hz classique. Sans entraînement, c’est difficile à percevoir consciemment, mais la plupart des gens peuvent le « sentir », même s’ils ne savent pas l’expliquer
Bien sûr, pour beaucoup d’utilisateurs, le taux d’interrogation de la souris à 125 Hz est aussi un facteur de confusion, mais ici une souris 1 kHz a été utilisée
Un écart de 7 ms n’est pas mauvais, mais un écart de 16,6 ms commence à devenir assez important. Personnellement, je pense que les ordinateurs devraient viser une latence de 1,6 image : une demi-image de phase aléatoire, une image, et un peu de temps de traitement
Les résultats varieront selon le compositeur, le GPU et la configuration. Sous X11, il y a en pratique une seule implémentation du serveur X utilisée par les systèmes de bureau Linux, donc ces écarts sont moins marqués
Il peut encore y avoir un problème, avec de nombreuses combinaisons compositeur/GPU, où l’on n’obtient pas le plan de curseur matériel ; dans ce cas, ce type d’écart de latence peut tout à fait apparaître
Je l’ai appris aujourd’hui, mais Wayland a déjà 16 ans. Dans quelques années, il aura l’âge qu’avait X au moment de la sortie de Wayland, et il semble toujours être considéré comme quelconque, voire inférieur à X
$very_specific_feature» ou que « je suis triste parce que le pilote propriétaire du fabricant de ma carte graphique n’est pas assez testé sous Wayland »Environ 99,999 % de ces plaintes viennent de personnes qui 1) ne travaillent pas elles-mêmes dessus, 2) n’ont ni l’intérêt ni la capacité de le faire, et 3) ne comprennent pas, ou refusent d’admettre, que les développeurs de Wayland et de X sont en grande partie les mêmes personnes, et qu’elles ne veulent plus travailler sur X11
Je n’ai pas d’enjeu particulier dans ce débat, mais je suis fatigué de voir des gens se plaindre de Wayland tout en utilisant un logiciel que d’autres leur fournissent gratuitement. S’il y a autant de plaintes contre Wayland, ils auraient déjà pu se regrouper pour maintenir et améliorer X et, si leurs plaintes et leurs théories sont justes, laisser Wayland derrière eux
Curieusement, X est open source et peut être forké à volonté ; malgré le précédent de X.org issu de XFree86, ses partisans le laissent prendre la poussière et ne font rien pour sa maintenance
Je regarderais avec beaucoup d’intérêt un résultat du type « Wayland n’est pas aussi bon que X, donc nous avons créé un fork modernisé de X que tout le monde peut utiliser »
Autrement dit, Wayland n’a qu’environ 66 % de l’âge qu’avait X lorsque Wayland est sorti, et il lui faut encore 50 % de sa durée de vie actuelle pour atteindre le même âge
J’utilise actuellement Wayland avec Plasma 6 et ça fonctionne suffisamment bien, mais je n’ai pas d’exigences particulières, donc je ne sais pas, par exemple, à quel point les lecteurs d’écran fonctionnent bien
À ce moment-là, je m’attends à ce que les stacks frontend de navigateur aient complètement dévoré le desktop. De toute façon, il n’y avait pas non plus tant de nouvelles apps desktop qui sortaient sous Linux
Il n’est pas surprenant que la plupart des tentatives de réécrire une solution fonctionnelle au motif qu’elle serait « plus moderne, plus facile à maintenir et mieux préparée pour l’avenir » n’aboutissent pas à cela. En général, cela devient plus lent, la latence augmente, et c’est simplement du matériel plus rapide qui compense, pas le logiciel qui devient plus rapide
J’ai l’impression que tous les 20 ans, une nouvelle génération s’appuie comme un enfant gâté sur les abstractions que la génération précédente a créées à force de travail difficile, et devient plus faible. Après environ trois générations de développeurs logiciel, il ne reste plus que des appelants de bibliothèques/frameworks, et presque plus personne ne comprend vraiment les performances et l’optimisation
Wayland a encore des fonctionnalités manquantes par rapport à X11, mais je suis prêt à faire ce compromis au vu de ses autres avantages
Plusieurs compositeurs Wayland ont de gros problèmes avec les claviers, les souris et d’autres périphériques d’entrée. C’est parce que la spécification Wayland et l’implémentation de référence ont choisi de ne pas prendre cela en charge. Chaque compositeur Wayland choisit donc sa propre solution
Les choix courants sont libei et libinput, mais les entrées souris/clavier « avancées » ne sont souvent pas prises en charge du tout. weston en est un exemple. Il est impossible de savoir si un logiciel Linux donné fonctionnera dans un environnement Wayland donné, et la fragmentation est sérieuse
Sous X, il existe une référence X11 forte qui implémente pratiquement tout, ce qui permet d’être certain que si quelque chose fonctionne à un endroit, cela fonctionnera ailleurs
Même après 12 ans, il n’existe toujours pas un seul compositeur Wayland qui prenne en charge les lecteurs d’écran pour les personnes aveugles. C’est du niveau d’un jouet
Donc ce n’est pas bon pour les jeux, pas bon pour le travail graphique professionnel, et pas bon pour les personnes ayant une mauvaise vue. Au final, cela veut dire que ce n’est globalement pas bon pour les utilisateurs qui diffèrent un tant soit peu de ses créateurs
Mais avec un peu de chance, cela a peut-être réduit le tearing que je n’ai jamais ressenti moi-même
L’un des résultats intéressants qui en est sorti, c’est de voir des gens ajouter des workflows d’accessibilité par-dessus cet écosystème. Quelqu’un contrôle tout son bureau avec la voix via un gestionnaire de fenêtres en tuiles : https://youtu.be/fiPJLmhnnXM
Quand le GPU est fortement sollicité, par exemple lors d’une inférence Stable Diffusion, de gros pics de latence apparaissent. Je n’ai pas fait de test A/B avec X11, mais je n’ai pas ce souvenir d’avant
Avoir une image de latence supplémentaire n’est déjà pas idéal, mais les pics de latence occasionnels sont vraiment agaçants
La latence du curseur est une nuisance qui érode en permanence la satisfaction vis-à-vis d’une application ou d’un système d’exploitation
Latence du curseur texte dans l’IDE ? Inacceptable
Latence du curseur texte dans le shell ? Inacceptable
Latence du curseur de souris dans l’interface graphique ? Inacceptable
Tout cela est un motif d’élimination immédiat
Même System 1, qui tournait il y a plus de 40 ans sur du matériel presque infiniment moins puissant, plaçait la réactivité du curseur au-dessus de tout et devançait toute la concurrence. Les fondations actuelles des OS et des UI sont totalement différentes, mais cette priorité est toujours maintenue
J’ai récemment subi d’énormes ralentissements de la souris avec la combinaison X11 et NVidia sous KDE/Plasma 6. J’ai remarqué que c’était particulièrement marqué au-dessus des onglets du navigateur
Pour ceux qui rencontrent le même problème, la solution a été de désactiver OpenGL flipping. Je n’ai aucune idée de ce que fait OpenGL flipping, mais le désactiver dans nvidia-settings et dans
/etc/X11/xorg.confa réglé le problèmeJ’aimerais bien que quelqu’un explique pourquoi, ou pourquoi ce n’est pas le réglage par défaut
Beau travail. Il vaudrait peut-être la peine de refaire l’expérience avec un moniteur réglé sur une fréquence de rafraîchissement très basse, par exemple 30Hz
Si Wayland a toujours une image de retard par rapport à X11, ce sera beaucoup plus facile à observer
J’ai une autre frustration personnelle, un peu différente. Quand j’ai commencé à utiliser Linux, le bureau faisait de la composition logicielle. Le CPU dessinait probablement l’UI en RAM avant de la blitter vers le framebuffer du GPU, et j’imagine que c’était ainsi depuis longtemps
Avec l’arrivée des compositeurs, y compris X11 composite, puis la popularisation des moteurs de rendu GPU, la latence est devenue terrible, littéralement de l’ordre de centaines de ms. Ayant grandi avec des jeux DOS, où ce problème n’existait pas, cela me semblait étrange
Les choses se sont améliorées avec le temps, mais je ne sais pas vraiment si nous sommes revenus à l’âge d’or du rendu CPU