- Les environnements Wayland existants reposaient sur une architecture où le compositeur et le gestionnaire de fenêtres formaient un seul programme, mais river 0.4.0 les sépare en processus distincts
- Le nouveau protocole river-window-management-v1 confère au gestionnaire de fenêtres l’autorité complète sur les politiques comme le placement des fenêtres et les raccourcis clavier, tout en préservant la perfection d’image (frame perfection) et les performances
- Cette architecture fonctionne sans latence d’entrée (latency) et garantit un rendu propre, même avec des dispositions en mosaïque complexes, grâce à des mises à jour d’état atomiques
- Grâce à cette séparation, le gestionnaire de fenêtres peut être développé et redémarré indépendamment, et il devient plus facile à implémenter même dans des langages de haut niveau
- Cette approche favorise une plus grande diversité des gestionnaires de fenêtres dans l’écosystème Wayland, et river prend déjà en charge plus de 15 gestionnaires compatibles
Structure traditionnelle de Wayland et approche de séparation de river
- Les compositeurs Wayland traditionnels intègrent en un seul processus trois rôles : serveur d’affichage, compositeur et gestionnaire de fenêtres
- Le serveur d’affichage achemine les événements d’entrée et transmet les buffers d’affichage au noyau
- Le compositeur assemble les buffers de plusieurs fenêtres pour produire l’écran final
- Le gestionnaire de fenêtres applique les politiques utilisateur, comme le placement des fenêtres et les raccourcis clavier
- Dans l’architecture X11, le serveur d’affichage existe comme processus séparé, ce qui entraîne des allers-retours inutiles et de la latence
- Wayland a résolu ce point en intégrant serveur et compositeur, mais il n’est pas nécessaire d’y coupler aussi le gestionnaire de fenêtres
- river défait ce couplage en séparant le gestionnaire de fenêtres dans un programme distinct
Principes de conception du protocole river-window-management-v1
- Conçu pour que le gestionnaire de fenêtres dispose d’un contrôle maximal tout en conservant les avantages de Wayland
- Aucun aller-retour n’est nécessaire à chaque frame ou événement d’entrée, donc aucune latence d’entrée
- Maintien de la perfection d’image (frame perfection) : lors de l’ouverture d’une fenêtre ou d’un changement de taille, l’actualisation de l’écran se fait sans trous ni chevauchements
- Le rendu est différé jusqu’à ce que toutes les fenêtres aient soumis leur nouveau buffer, avec un traitement par timeout au-delà d’un certain délai
- Plus une application est bien implémentée, plus une synchronisation complète des frames est possible
Architecture de gestion de fenêtres fondée sur une machine à états
- Le protocole sépare l’état en état de gestion des fenêtres et état de rendu
- État de gestion des fenêtres : taille des fenêtres, mode plein écran, focus clavier, raccourcis clavier, etc.
- État de rendu : position des fenêtres, ordre, décorations, recadrage, etc.
- Les modifications sont regroupées et traitées sous forme de mises à jour atomiques (
manage/render sequence)
- Le compositeur démarre la séquence et, en l’absence de changement d’état, le gestionnaire de fenêtres reste en attente
- Cette structure formalise explicitement des concepts déjà présents de manière implicite dans river-classic, sway et d’autres
Avantages de l’architecture séparée
- Les développeurs de gestionnaires de fenêtres peuvent se concentrer uniquement sur les politiques, sans avoir à implémenter l’ensemble du compositeur
- Débogage et redémarrage sont facilités, et un crash du gestionnaire de fenêtres n’entraîne pas la fin de la session
- Même écrit dans un langage à ramasse-miettes, il n’y a pas de perte de performances ni de retard d’affichage
- Il existe déjà plus de 15 gestionnaires de fenêtres compatibles avec river, avec l’espoir d’atteindre une diversité comparable à celle de X11
Limites et feuille de route
- Le protocole actuel ne prend en charge que les environnements de bureau 2D ; la VR et d’autres usages ne sont pas pris en charge
- Les effets visuels complexes (par exemple des fenêtres qui ondulent) sortent du périmètre, mais des animations simples restent possibles
- La prise en charge de shaders personnalisés est envisagée à l’avenir, sans être prévue à court terme
- river 0.4.0 est déjà suffisant pour un usage quotidien, et des améliorations de l’UX sont prévues avant le passage en version 1.0.0
- Pour poursuivre le développement, un soutien est sollicité via liberapay, GitHub Sponsors, Ko-fi
Exemples et galerie
- Présentation de plusieurs exemples de gestionnaires de fenêtres fonctionnant avec river
- Canoe : gestionnaire de fenêtres empilé classique
- reka : gestionnaire de fenêtres basé sur Emacs
- tarazed : environnement de bureau centré sur la concentration
- rhine : gestion récursive et modulaire des fenêtres avec prise en charge des animations
- Il existe également de nombreux autres gestionnaires de fenêtres compatibles avec river
Aucun commentaire pour le moment.