URL: https://linuxfr.org/users/phhusson/journaux/le-point-sur-les-bureaux-3d Title: Le point sur les bureaux 3D Authors: Ph Husson Date: 2006年02月22日T23:42:27+01:00 Tags: compiz Score: 0 L'actualité est riche pour les bureaux 3D, Annonce de AIGLX [1], Ouverture de compiz par Novell [2]et je vais tâcher de vous expliquer comment ces bureaux fonctionnent et leur différences, bonne lecture :) Déjà le terme de bureau que j'utilise est faux, En fait je devrais plutôt dire qu'on a trois ensemble WM <-> serveur X modifié, mais bon je trouve bureau plus approprié, faites un sed s/bureau(|x)/WM/g de mon article si ça vous convient mieux. En fait ces bureaux ne fournissent aucune application, et sont "justes" des serveurs X, qui affichent des clients X (de manière spéciale certes). Pour ce faire il y a deux choses à faire comparé à un serveur X normal: 1.Mettre le contenu de toutes les fenêtres en mémoire d'un client X un peu spécial (au même titre que le gestionnaire de fenêtres) 2.Calculer le rendu du touillage de toutes ces fenêtres (sur certaines démo ça tien vraiment du touillage ;) Ces deux étapes se mettent donc à la place du rendu habituel. Globalement la méthode utilisée est la même dans les deux cas Xglx et AIGLX qui utilisent l'extension maintenant connue (en partie pour ses bogues) appelée "Composite". Cette extension consiste en l'envoi à un client X spécial du contenu de toutes les fenêtres ce client X est appelée le composite manager. Une fois que le composite manager a ces informations il en fait ce qu'il en veut, mais il doit renvoyer au serveur X un rendu. Pour les composite manager habituels le rendu, c'est l'affichage des fenêtres telles qu'elles devraient l'être avec de la transparence et des ombres et ce de manière accélérée par Xrender qui est une extension de calcul rapide sur des images (de ce que j'ai compris) , mais ils font strictement ce qu'ils veulent, vous pouvez coder un composite manager, qui met les fenêtres la tête à l'envers si vous voulez, qui fait des miniatures, etc. Mais ils peuvent faire le rendu comme ils veulent, pas seulement avec XRender, et donc Xgl et AIGLX font le rendu.... par OpenGL?! (Tant qu'à faire) Et donc on a le droit au fameux cube ou tout ce que vous voulez. Mais alors pourquoi Compiz|Xgl et AIGLX ont eu besoin de modifier le serveur X? La seule raison que j'ai trouvé est qu'il est nécessaire (bon grandement plus optimisé et simple du moins), d'avoir une extension OpenGL? ce coup ci (et plus Xorg, vous suivez ? :) qui permettent de définir une texture OpenGL? directement à partir du contenu de la fenêtre fourni par le serveur X, et dans aussi bien pour Xglx que pour AIGLX. Une fois cette extension (répondant au doux nom de GLX_EXT_texture_from_pixmap) ajoutée, les différents composite manager 3D marchent, aussi bien compiz que glxcompmgr que metacity donc compiz peut marcher sur AIGLX, metacity sur xgl (modulo les bogues comme toujours). Fait à noter, NVIDIA à annoncé à l'équipe de AIGLX qu'ils ajouteraient le support de GLX_EXT_texture_from_pixmap, ce qui si vous avez tout suivi (on ne sait jamais tout peut arriver), vous dit qu'on pour avoir des bureaux 3D sans rien faire à part installer le composite manager (un configure && make install suffit dans la plupart des cas). Maintenant pourquoi deux projets distincts, pourquoi des désaccords de toute part ? Le but premier de Xgl N'est PAS de faire un bureau 3D, il vient principalement de vous là ! oui le petit qui râle tout le temps! Ceux qui râlent que X est lent, ceux qui détaillent pourquoi ils râlent, disent que X est trop complexe et qu'il faudrait s'appuyer sur une couche OpenGL? qui est accélérée, alors que la couche 2D ne l'est pas (Qu'ils disent ! Car c'est faux (je précise quand même au cas où)), et aussi ceux qui disent que développer un driver X est compliqué et que X devrait se baser sur OpenGL?. En clair, Xgl est un serveur X qui tire son accélération 2D de l'OpenGL? (de la 3D avec z=0 quoi). Xgl n'est pas exactement un serveur, c'est une architecture avec 2 grandes variantes, Xglx et Xegl, je reparlais de ce dernier plus loin, mais d'abord Xglx, le serveur dont on parle le plus souvent Xglx est un client X et a donc besoin d'un serveur X pour fonctionner, hors le but d'un serveur X se basant sur OpenGL? c'est de ne pas à avoir à écrire de driver X.... vous comprenez la connerie ? Alors pour certain c'est intelligent, mais bon l'égout les couleurs ... Sinon à côté de Xglx on entend parlé de Xegl, et que Mandriva ne supporterait officiellement que Xegl et pas Xglx, on a vu que ne pas supporter Xgxl ou le supporter.... ça changeait pas grand chose à la vie en somme, Xegl est parait-il son petit frère donc tout aussi inutile ? Pas tout à fait, la différence entre Xegl et Xglx est que Xegl ne s'appuie pas sur X mais sur OpenGL? ES, je vous vois venir "C'est quoi ce monstre?" c'est juste une API OpenGL? pour l'embarqué, de sorte que l'application n'ait pas de serveur X ou équivalent, on pourait le comparer au framebuffer linux. On a donc ici un OpenGL? ES et pas de driver X et on en sort un serveur X accéléré aussi bien pour la 2D que la 3D sans autre effort, le but est donc atteint, mais ce n'est pas forcement une solution comme l'explique NVIDIA dans [3] (ca commence sérieusement page4) [1] [http://linuxfr.org/~etb/20923.html](http://linuxfr.org/~etb/20923.html) [2] De nombreux journaux et une news que je retrouve pas [3] [http://download.nvidia.com/developer/presentations/2006/xdev(...)](http://download.nvidia.com/developer/presentations/2006/xdevconf/compositing-with-current-framework.pdf) Vous avez réussi à me lire jusqu'au bout? Et bien je vous remercie et vous dis bravo :) PS Au début je voulais parler de metisse et de lg3d mais bon ce journal est déjà bien long :) Enfin on pourra signaler l'ouverture d'un CVS public de metisse (la dernière release commençant à dater)