Mais dans l'état actuel des choses, on utilise seulement un seul compositeur
On en utilise même souvent 0. A l'heure actuelle on peut parfaitement se passer des différents "display compositors" et avoir un système qui marche très bien. Sauf que là la règle va changer, on va en fait avoir des cascades de compositors.
Déjà le compositor final Wayland, ensuite probablement au moins un des clients (ou plugins du serveur wayland ?) sera un composite window manager.
Ensuite se pose les problèmes de tout ce qui utilise les backbuffers, l'accès direct ou l'overlay (video, 2D/3D accéléré etc.) Parceque ça fait pas forcément très bon ménage avec les compositors. Bien sur il existe des solutions qui marchent, mais il va falloir faire des choix et définir des priorités. Par exemple que se passe-t-il sur un contenu webGL dans firefox ? Est-ce que l'on fait un rendu complet de tout le WebGL et qu'on l'envoi à Wayland ? Est-ce qu'on créé un hook dans Wayland pour qu'il fasse le rendu webGL lui-même (avec ou sans aide de Firefox qui peut prémacher une partie du boulot) ou est-ce qu'on définit une zone buffer dans Wayland dans laquelle il n'y a pas de composing et ou le rendu se fait en direct ? Ou alors est-ce qu'on multiplie les API pour garder la compatibilité (et dans ce cas je sens qu'on va encore jouer à "ou qu'elle est la doc ? D T Code !")
Chez OSX, qui est un peu le leader sur les techniques de composing dans les ordis grand public, ils ont été amenés a créer un chef d'orchestre pour mettre un peu d'ordre dans toutes les priorités des différentes applis de composing (mission control). Et pourtant eux ils avaient plus ou moins table rase de l'historique. Chose que Linux va avoir du mal à faire.
Donc plusieurs compositors c'est à peu près obligatoire, reste à savoir si on pourra avoir plusieurs moteurs de composing en même temps. Si oui, comment vont-ils dialoguer ensemble pour pas se taper sur la gueule (pas DBus, pitié pas DBus), sinon est-ce que le moteur "officiel" de Gnome sera compatible avec celui de KDE ou avec celui d'enlightenment...
[^] # Re: Gestionnaire de fenêtres
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 2.
Mais dans l'état actuel des choses, on utilise seulement un seul compositeur
On en utilise même souvent 0. A l'heure actuelle on peut parfaitement se passer des différents "display compositors" et avoir un système qui marche très bien. Sauf que là la règle va changer, on va en fait avoir des cascades de compositors.
Déjà le compositor final Wayland, ensuite probablement au moins un des clients (ou plugins du serveur wayland ?) sera un composite window manager.
Ensuite se pose les problèmes de tout ce qui utilise les backbuffers, l'accès direct ou l'overlay (video, 2D/3D accéléré etc.) Parceque ça fait pas forcément très bon ménage avec les compositors. Bien sur il existe des solutions qui marchent, mais il va falloir faire des choix et définir des priorités. Par exemple que se passe-t-il sur un contenu webGL dans firefox ? Est-ce que l'on fait un rendu complet de tout le WebGL et qu'on l'envoi à Wayland ? Est-ce qu'on créé un hook dans Wayland pour qu'il fasse le rendu webGL lui-même (avec ou sans aide de Firefox qui peut prémacher une partie du boulot) ou est-ce qu'on définit une zone buffer dans Wayland dans laquelle il n'y a pas de composing et ou le rendu se fait en direct ? Ou alors est-ce qu'on multiplie les API pour garder la compatibilité (et dans ce cas je sens qu'on va encore jouer à "ou qu'elle est la doc ? D T Code !")
Chez OSX, qui est un peu le leader sur les techniques de composing dans les ordis grand public, ils ont été amenés a créer un chef d'orchestre pour mettre un peu d'ordre dans toutes les priorités des différentes applis de composing (mission control). Et pourtant eux ils avaient plus ou moins table rase de l'historique. Chose que Linux va avoir du mal à faire.
Donc plusieurs compositors c'est à peu près obligatoire, reste à savoir si on pourra avoir plusieurs moteurs de composing en même temps. Si oui, comment vont-ils dialoguer ensemble pour pas se taper sur la gueule (pas DBus, pitié pas DBus), sinon est-ce que le moteur "officiel" de Gnome sera compatible avec celui de KDE ou avec celui d'enlightenment...