Un serveur X par dessus OpenGL serait plus rapide
Peut-être un peu. On associe souvent (parfois inconsciemment) OpenGL et rapidité, et on oublie que ce n'est qu'une API, une manière d'attaquer le driver.
Ce qui parait logique car d'après Jon Smirl ancien développeur de XGL/XEGL « la 3D est simplement plus rapide que la 2D, personne ne rend ses fonctions 2D plus rapides, toute la technologie silicium entre dans la 3D ». Toujours d'après Jon Smirl : « Dans certains cas ces nouveaux bureaux accélérés (par le GPU) peuvent s'afficher plus de cent fois plus rapidement que sur un ancien modèle. »
Xgl se sert aussi d'une nouvelle fonctionnalité d'OpenGL, les objets framebuffer (FBO) qui pour une application a l'apparence d'une fenêtre de dessin normale. Mais pour le gestionnaire de fenêtres, les fenêtres ressemblent à des textures et peuvent être manipulées avec des commandes de dessin normales comme le multitexture. Un gestionnaire de fenêtres basé sur OpenGL comme Luminosity peut combiner des fenêtres en utilisant un z-buffer et supprimer les limites de l'ordre Z strictement 2D et transformer une fenêtre en vague et à plusieurs reprises entrecroiser une autre fenêtre.
L'intérêt d'avoir un serveur X basée sur OpenGL et aussi de n'avoir qu'un seul pilote à maintenir au lieu des pilotes XAA, OpenGL à maintenir. Sans compter sur les nouveaux pilotes EXA.
X.org a choisi une solution à court terme en implémentant le sparadrap EXA repoussant ainsi la sortie du prometteur XGL de deux années. EXA/Render est uniquement un sous-ensemble de l'API générique OpenGL Mesa et risque d'être engraissé de nouvelles fonctionnalités, alors qu'avec OpenGL il est possible d'avoir une seule API pour tout.
[^] # Re: Cher Père Noël...
Posté par Bruno Ethvignot (site web personnel) . En réponse à la dépêche X11R7.0 sous le sapin de Noël. Évalué à 10.
Un serveur X par dessus OpenGL serait plus rapide
Peut-être un peu. On associe souvent (parfois inconsciemment) OpenGL et rapidité, et on oublie que ce n'est qu'une API, une manière d'attaquer le driver.
D'après les vidéos des démos de XGL (le serveur X au-dessus d'OpenGL) le déplacement des fenêtres sont bigrement plus rapides :
http://vizzzion.org/stuff/xgl_wanking.avi
http://www.gnome.org/%7Eseth/blog-images/monkey-hoot/mpeg4/W(...)
Ce qui parait logique car d'après Jon Smirl ancien développeur de XGL/XEGL « la 3D est simplement plus rapide que la 2D, personne ne rend ses fonctions 2D plus rapides, toute la technologie silicium entre dans la 3D ». Toujours d'après Jon Smirl : « Dans certains cas ces nouveaux bureaux accélérés (par le GPU) peuvent s'afficher plus de cent fois plus rapidement que sur un ancien modèle. »
Xgl se sert aussi d'une nouvelle fonctionnalité d'OpenGL, les objets framebuffer (FBO) qui pour une application a l'apparence d'une fenêtre de dessin normale. Mais pour le gestionnaire de fenêtres, les fenêtres ressemblent à des textures et peuvent être manipulées avec des commandes de dessin normales comme le multitexture. Un gestionnaire de fenêtres basé sur OpenGL comme Luminosity peut combiner des fenêtres en utilisant un z-buffer et supprimer les limites de l'ordre Z strictement 2D et transformer une fenêtre en vague et à plusieurs reprises entrecroiser une autre fenêtre.
L'intérêt d'avoir un serveur X basée sur OpenGL et aussi de n'avoir qu'un seul pilote à maintenir au lieu des pilotes XAA, OpenGL à maintenir. Sans compter sur les nouveaux pilotes EXA.
X.org a choisi une solution à court terme en implémentant le sparadrap EXA repoussant ainsi la sortie du prometteur XGL de deux années. EXA/Render est uniquement un sous-ensemble de l'API générique OpenGL Mesa et risque d'être engraissé de nouvelles fonctionnalités, alors qu'avec OpenGL il est possible d'avoir une seule API pour tout.