pourquoi pas, sauf qu'ici aussi ,le gestionnaire de fenêtre à peu de travail à effectuer: le mode fenêtré en question prend un de mes écrans en entier ;) on peut presque dire qu'il s'agit d'un mode fullscreen, au final. Presque. )
Sauf que pas de bol, mais X ne peut pas gerer les ecrans individuellements et faire un rendu direct (en evitant une copie) dans ce scenario la. Avec Wayland, si les deux surfaces matchs, il est possible d'avoir un chemin raccourci et de pouvoir utiliser directement le buffer de l'application pour la sortie lie a l'ecran en question.
plus spécialisé que Xorg ( ne fait qu'une chose, on peut donc espérer qu'il la fera bien. )
Ca par contre, c'est un peu faux. Il y a beaucoup plus de boulot dans une implementation de Wayland que dans une implementation de X. Simplement parce que le windows manager, le composite manager et X ont ete merge ensemble.
portable ( avec un peu de bol, quelqu'un finira peut-être par en faire serveur pour windows, histoire d'enrichir nos kits de survie en environnement hostile /me rêve )
Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer. Ce qui veut dire qu'il faut se taper la dite manipulation par cible potentiel (Et le projet Wayland n'est pour l'instant pas interresse par une telle bibliotheque). Et oui la gestion des buffers video sous Linux, Android, RPi, ... est differente. Donc la portabilite est aussi complique que celle de X, sauf qu'il faut penser a porter CHAQUE implementation de Wayland completement...
de la diversité ... kfreebsd ...
Et bien justement, vu qu'on parle de portabilite, tu vas avoir quelques restrictions pour Wayland sur Freebsd. Avec un peu de chance tu auras un backend fbdev.
avec un peu de bol, moins pénible a configurer que Xorg?
Ca, ca dependra de chaque implementation. Avec un peu de chance, sous GNOME, ils n'auront meme pas mis d'option de configuration :-D
[^] # Re: Gestionnaire de fenêtres léger
Posté par cedric . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 2.
Sauf que pas de bol, mais X ne peut pas gerer les ecrans individuellements et faire un rendu direct (en evitant une copie) dans ce scenario la. Avec Wayland, si les deux surfaces matchs, il est possible d'avoir un chemin raccourci et de pouvoir utiliser directement le buffer de l'application pour la sortie lie a l'ecran en question.
Ca par contre, c'est un peu faux. Il y a beaucoup plus de boulot dans une implementation de Wayland que dans une implementation de X. Simplement parce que le windows manager, le composite manager et X ont ete merge ensemble.
Ca aussi, c'est assez mal informe. Il n'y a pas de bibliotheque d'abstraction du systeme de buffer. Ce qui veut dire qu'il faut se taper la dite manipulation par cible potentiel (Et le projet Wayland n'est pour l'instant pas interresse par une telle bibliotheque). Et oui la gestion des buffers video sous Linux, Android, RPi, ... est differente. Donc la portabilite est aussi complique que celle de X, sauf qu'il faut penser a porter CHAQUE implementation de Wayland completement...
Et bien justement, vu qu'on parle de portabilite, tu vas avoir quelques restrictions pour Wayland sur Freebsd. Avec un peu de chance tu auras un backend fbdev.
Ca, ca dependra de chaque implementation. Avec un peu de chance, sous GNOME, ils n'auront meme pas mis d'option de configuration :-D