PorteuX a livré avec sa version 2.8 un banc d'essai qui fait ce que la plupart des comparaisons Wayland contre X11 ne font pas : chaque binaire de test embarque un vrai backend X11 et un backend Wayland natif, et choisit au démarrage, donc rien ne passe discrètement par XWayland. Le constat que le projet énonce sans détour est que Wayland est intrinsèquement plus rapide que X11, mais pas forcément plus économe. Sur un Ryzen 7 7840HS à graphismes Radeon 780M, les sessions qui ont consommé le moins de puissance et de processeur n'étaient pas les sessions Wayland. LXDE avec Openbox arrive en tête, Xfce avec le fork maison xfwm4-gl en deuxième.
The short answer
PorteuX a publié wmbench avec sa version 2.8, un banc d'essai de gestionnaires de fenêtres dans lequel chaque binaire de test embarque un backend X11 natif et un backend Wayland natif et choisit au démarrage, afin que les résultats ne soient pas faussés par XWayland. Le nombre d'images est mesuré sans bride, tandis que processeur et puissance sont mesurés avec la même charge bridée à soixante images par seconde. Le résumé du projet est que Wayland est intrinsèquement plus rapide que X11 mais pas forcément plus économe. Sur un Ryzen 7 7840HS à Radeon 780M, les consommations les plus basses viennent de LXDE avec Openbox, puis de Xfce avec xfwm4-gl.
Presque tous les bancs d'essai Wayland contre X11 que vous avez lus comportent une couche de compatibilité quelque part. C'est exactement ce que wmbench est construit pour éviter, et c'est pourquoi le résultat mérite lecture même si ce débat vous lasse.
La méthode est l'information
PorteuX a publié wmbench avec sa version 2.8. Le choix de conception qui compte est que chaque binaire de test livre deux backends de rendu, un vrai backend X11 et un backend Wayland natif, et retient le bon au démarrage.
Cela paraît mineur et ne l'est pas. Dans la plupart des comparaisons publiées, au moins un des deux camps passe par XWayland, donc une partie de ce qui est chronométré relève de la traduction entre protocoles plutôt que d'un protocole pris pour lui même. Retirez cela et vous comparez les piles, non le pont entre elles.
L'outil refuse aussi de simuler une couverture. Il sonde les protocoles qu'un compositeur implémente réellement et saute les tests qu'il ne peut pas y exécuter honnêtement, au lieu de rapporter ce qu'un chemin de repli aurait produit. À côté des mesures de performance figurent neuf tests de défauts visuels, couvrant le déchirement, les images périmées, les artefacts de menus, le comportement à la mise en veille de l'écran et les ratés de redimensionnement, soit la catégorie de problèmes que les bancs d'essai ignorent d'ordinaire et que les utilisateurs remarquent en premier.
Vitesse et sobriété se mesurent différemment
C'est le détail qui rend le constat cohérent plutôt que contradictoire.
Le nombre d'images est mesuré avec le banc d'essai lancé aussi vite qu'il peut aller, en fenêtré et en plein écran. Cela répond à la question de ce dont la pile est capable quand rien ne la contraint.
L'usage processeur et la puissance appelée sont mesurés avec le même banc d'essai bridé à soixante images par seconde. Chaque session accomplit alors un travail identique et fixe, et la question devient combien de silicium et combien de watts il a fallu pour l'accomplir. Les relevés de puissance viennent de capteurs matériels sur le processeur et le GPU. Sous X11, la comptabilité processeur couvre le gestionnaire de fenêtres et le serveur X, sous Wayland elle couvre le compositeur.
Mesurez la vitesse sans bride et la sobriété sous bride, et il devient tout à fait possible qu'un protocole gagne la première et perde la seconde. C'est exactement ce qui s'est produit.
Ce qui arrive en tête
Sur le nombre d'images, Wayland mène. KDE Plasma sous Wayland se comporte très bien, aux côtés de labwc et de COSMIC.
Sur la puissance et le processeur, le classement s'inverse. La machine de test était un Ryzen 7 7840HS à graphismes intégrés Radeon 780M avec 32 Go de mémoire sous PorteuX 2.8, et les sessions qui ont tiré le moins de puissance et employé le moins de processeur n'étaient pas les sessions Wayland. LXDE avec Openbox arrive premier, Xfce avec xfwm4-gl deuxième.
Le résumé du projet mérite d'être pris au mot : Wayland est intrinsèquement plus rapide que X11, mais pas forcément plus économe, et pour la composition en particulier, Openbox exclu, xfwm4-gl est le meilleur du lot.
Cette exclusion compte. Openbox ne fait aucune composition, il n'accomplit donc pas le même travail qu'un compositeur gérant des tampons et la présentation image par image. Le lire comme un concurrent exagère le propos. Le lire comme un plancher, le coût de la composition exprimé en watts, est plus utile.
xfwm4-gl, le fork en deuxième place
xfwm4-gl est un fork de xfwm4, le gestionnaire de fenêtres de Xfce, maintenu par le développeur de PorteuX, qui ajoute la composition OpenGL à un gestionnaire dont la réputation a toujours été un faible surcoût assorti d'un compositeur modeste.
Terminer deuxième en puissance comme en processeur, derrière la seule session ne faisant aucune composition, est une belle performance pour un fork plutôt qu'une réécriture amont. Si vous faites tourner Xfce sur un portable et tenez à l'autonomie, cela vaut la peine d'être connu.
Comment lire cela si vous administrez des postes
Une machine, une distribution, des graphismes AMD intégrés. Voilà le périmètre, et le projet a été plus soigneux que la moyenne à l'énoncer.
Dans ce périmètre, la conclusion pratique est étroite et utile. Si l'autonomie est ce que vous optimisez, une session X11 légère avec peu de composition reste compétitive sur du matériel de 2026, et elle a gagné dans ce test. Si ce sont le nombre d'images, la latence, les fréquences de rafraîchissement mixtes ou la mise à l'échelle fractionnaire qui vous importent, rien ici ne plaide contre les raisons qui ont poussé les gens vers Wayland, et le versant Wayland de l'écosystème continue de livrer.
La contribution la plus durable reste l'outil. Un banc d'essai qui embarque nativement les deux backends, saute les tests qu'il ne peut pas mener honnêtement et sépare la vitesse sans bride de la sobriété sous bride est un meilleur instrument que les querelles qu'il servira à trancher. Le versant X11 ne reste pas immobile non plus, comme le suggère un serveur X11 en Rust atteignant Steam et les charges GPU. Disposer d'une façon équitable de mesurer les deux se faisait attendre.
Sources et pour aller plus loin
- Wayland Found To Be "Intrinsically Faster Than X11, But Not Necessarily More Efficient", Phoronix, août 2026
- Wayland vs X11: Faster on Frames, Not on Watts, and an Xfce Fork Beats Both, Hardware Busters, août 2026
- wmbench, bancs d'essai et tests de défauts visuels pour gestionnaires de fenêtres Linux, GitHub
- xfwm4-gl, un compositeur forké de xfwm4 avec composition OpenGL, GitHub
Questions fréquentes
Qu'est ce qui distingue wmbench des comparaisons précédentes ?
Il retire la couche de compatibilité de la mesure. La plupart des chiffres Wayland contre X11 que vous lisez impliquent au moins une application passant par XWayland, ce qui signifie qu'une partie de ce qui est chronométré est de la traduction plutôt que le protocole lui même. Dans wmbench, chaque binaire de test livre un backend X11 natif et un backend Wayland natif, et sélectionne le bon au démarrage. L'outil sonde aussi les protocoles que parle réellement un compositeur donné et saute les tests qu'il ne peut pas exécuter honnêtement dessus, plutôt que de rapporter un chiffre produit par un chemin de repli.
Comment sont mesurés images, processeur et puissance ?
Dans des conditions volontairement différentes, et c'est ce qui rend le constat principal cohérent. Le nombre d'images est mesuré avec le banc d'essai lancé à pleine vitesse, en fenêtré et en plein écran, pour voir ce dont la pile est capable quand rien ne la retient. L'usage processeur et la puissance appelée sont mesurés pendant que le même banc d'essai est bridé à soixante images par seconde, de sorte que chaque session accomplisse un travail identique et fixe. La puissance provient de capteurs matériels sur le processeur et le GPU. Mesurer la vitesse sans bride et l'efficacité sous bride explique qu'un protocole puisse gagner la première et perdre la seconde.
Faut il en conclure qu'il faut revenir à X11 ?
Non, et le résultat ne soutient pas vraiment cette lecture. Ce qu'il soutient, c'est que si l'autonomie sur portable est votre préoccupation dominante, une session X11 légère avec peu ou pas de composition reste compétitive, et qu'elle a gagné dans ce test. C'est une affirmation étroite portant sur une machine à graphismes AMD intégrés exécutant une distribution. Elle ne dit rien des configurations multi écrans à fréquences mixtes, de la mise à l'échelle fractionnaire, des gestes de pavé tactile et des autres domaines qui ont motivé le passage à Wayland. Choisissez l'axe qui vous importe et mesurez le sur votre propre matériel.
Comparer Openbox à un compositeur Wayland est il équitable ?
Pas tout à fait à périmètre égal, et le projet le dit lui même. Openbox ne fait aucune composition, il n'accomplit donc pas le même travail qu'un compositeur qui gère des tampons, des effets et la présentation image par image. C'est précisément pourquoi le projet a nuancé sa propre conclusion : Openbox exclu, la session avec composition la plus économe du test est Xfce avec xfwm4-gl. Le résultat d'Openbox reste une information utile, car il chiffre ce que coûte la composition, mais il doit se lire comme un plancher plutôt que comme un concurrent.
Qu'est ce que xfwm4-gl ?
C'est un fork du gestionnaire de fenêtres xfwm4 de Xfce, maintenu par le développeur de PorteuX, qui ajoute la composition OpenGL. Le xfwm4 standard est depuis longtemps l'option légère qui le paie par un compositeur moins capable, et ce fork tente de conserver le faible surcoût tout en déplaçant le chemin de composition sur le GPU. Dans ce banc d'essai, il termine deuxième en puissance comme en processeur, derrière la seule session ne faisant aucune composition, ce qui est un bon résultat pour un fork plutôt qu'une réécriture amont. Les sources sont sur GitHub.