Dans la terminologie de X, le serveur X s'occupe la couche de communication (qui permet la transparence réseau) et le client s'occupe des entrées/sorties (clavier/souris/écran/autre). Donc là où on veut utiliser une application X, il faut obligatoirement un serveur X et là où on veut interagir avec une application X, il faut un client X (qui lance forcement un serveur X). Et où est ce serveur X ? c'est /usr/X11R6/lib/libX11.so :)
Pourquoi modifier le client Xorg ? Tout simplement parce que son architecture ne permet pas de faire ce qu'apporte AIGLX et Xgl : l'utilisation d'OpenGL pour la composition. Il faut l'extension GLX_EXT_texture_from_pixmap.
L'approche de Xgl est de rediriger les primitives 2D vers glitz (et donc OpenGL) alors que celle de AIGLX est de mettre au même niveau OpenGL et les pilotes graphiques du client X (puisqu'ils peuvent partager des XPixmaps). AIGLX est plus léger en terme de modification mais une vieille application en Xaw ne fera que de la 2D (au niveau du pilote graphique) alors que Xgl remet à plat beaucoup de choses mais permet d'avoir une utilisation de la 3D à tous les niveaux (même si certains toolkits ont moins d'intermédiaire que d'autres). Mais d'une manière générale, Xgl et AIGLX permettent bien de faire exactement la même chose. Personnellement, je ne vote ni pour Xgl ni pour AIGLX car je pense qu'un mélange des 2 est possible =)
X est lent car :
- la Xlib a des appels synchrones que les specs disent asynchrones (voir Xcb pour la réécrire de la Xlib pour corriger ce problème).
- certaines extensions sont exécutées par le processeur (donc besoin d'un processeur puissant puisqu'on a les applications *et* le client X qui le solicitent).
- autres problèmes dus à des pilotes buggués et/ou à code fermés.
Tu as entièrement raison, Xgl est un client X qui utilise OpenGL pour l'affichage. En revanche, je ne comprend pas ta phrase suivante :
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 ?
Tu confonds un peu tout. où est la "connerie" d'utiliser OpenGL dans le client X ? Le serveur X ne fait que gérer les communications entre application X et client X. Utiliser à distance une application Gtk+ (Gtk+ 2.8 avec glitz pour l'affichage) est toujours possible. Bref, tout va bien et rien n'a changé pour l'utilisateur. Et pourquoi ? Tout simplement parce que la couche basse (du toolkit ou Xglx lui même) à appelé GLX pour ouvrir un contexte GLX sur la machine cliente.
Pour EGL, c'est encore autre chose. EGL est une uniformisation de GLX/WGL/AGL (et d'autres s'ils existent). Donc on a une unique API pour gérer des contextes OpenGL (et donc le rendu). Après, que l'implémentation utilise X, MacOSX ou Ms Windows pour permettre leurs interactions, ce n'est plus un problème puisqu'une unique API permet de s'abstraire de l'environnement dans lequel on utilise l'application.
Si mon raisonnement etait erroné - càd qu'EGL est une couche à peine moins basse qu'OpenGL mais totalement indépendante de tout système de fenêtrage - il serait donc possible à X de s'appuyer dessus pour l'affichage mais le problème de l'absence de tranparence réseau impliquerait le développement d'une couche dans X pour le permettre ... on vient de réinventer GLX sauf qu'il s'appelerait EGLX \o/
Pour s'en convaincre, il suffit de comparer les specs de GLX et d'EGL ... elles se ressemblent beaucoup trop pour ne pas permettre les mêmes possibilités (la transparence réseau entre autre). En l'occurrence la même séparation entre un "état client" et un "état serveur" qui permet justement à GLX d'encapsuler les appels OpenGL dans le protocole X.
OpenGL/ES apparait effectivement comme étant une version pour embarqué d'OpenGL. Personnellement, je vois surtout une "remise à plat" d'OpenGL - ou plutôt une correspondance entre OpenGL/ES 1.0 et une version OpenGL 1.x donnée (je n'ai pas lu en profondeur les specs d'OpenGL/ES) - De plus, OpenGL/ES est montré comme étant une API 2D/3D totalement indépendante ... OpenGL l'est à l'origine (et ça doit remonter à IrisGL son ancêtre). D'ailleurs, pourquoi la libGL est-elle dans /usr/lib et non dans /usr/X11R6/lib ?
ayé, fini ^_^
ps: j'espère ne pas trop faire écho avec d'autres posts ... il y a presque 3h entre le début et la fin de mon roman /o\
# quelques clarifications et méditations
Posté par Rémi Hérilier . En réponse au journal Le point sur les bureaux 3D. Évalué à 9.
Pourquoi modifier le client Xorg ? Tout simplement parce que son architecture ne permet pas de faire ce qu'apporte AIGLX et Xgl : l'utilisation d'OpenGL pour la composition. Il faut l'extension GLX_EXT_texture_from_pixmap.
L'approche de Xgl est de rediriger les primitives 2D vers glitz (et donc OpenGL) alors que celle de AIGLX est de mettre au même niveau OpenGL et les pilotes graphiques du client X (puisqu'ils peuvent partager des XPixmaps). AIGLX est plus léger en terme de modification mais une vieille application en Xaw ne fera que de la 2D (au niveau du pilote graphique) alors que Xgl remet à plat beaucoup de choses mais permet d'avoir une utilisation de la 3D à tous les niveaux (même si certains toolkits ont moins d'intermédiaire que d'autres). Mais d'une manière générale, Xgl et AIGLX permettent bien de faire exactement la même chose. Personnellement, je ne vote ni pour Xgl ni pour AIGLX car je pense qu'un mélange des 2 est possible =)
X est lent car :
- la Xlib a des appels synchrones que les specs disent asynchrones (voir Xcb pour la réécrire de la Xlib pour corriger ce problème).
- certaines extensions sont exécutées par le processeur (donc besoin d'un processeur puissant puisqu'on a les applications *et* le client X qui le solicitent).
- autres problèmes dus à des pilotes buggués et/ou à code fermés.
Tu as entièrement raison, Xgl est un client X qui utilise OpenGL pour l'affichage. En revanche, je ne comprend pas ta phrase suivante :
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 ?
Tu confonds un peu tout. où est la "connerie" d'utiliser OpenGL dans le client X ? Le serveur X ne fait que gérer les communications entre application X et client X. Utiliser à distance une application Gtk+ (Gtk+ 2.8 avec glitz pour l'affichage) est toujours possible. Bref, tout va bien et rien n'a changé pour l'utilisateur. Et pourquoi ? Tout simplement parce que la couche basse (du toolkit ou Xglx lui même) à appelé GLX pour ouvrir un contexte GLX sur la machine cliente.
Pour EGL, c'est encore autre chose. EGL est une uniformisation de GLX/WGL/AGL (et d'autres s'ils existent). Donc on a une unique API pour gérer des contextes OpenGL (et donc le rendu). Après, que l'implémentation utilise X, MacOSX ou Ms Windows pour permettre leurs interactions, ce n'est plus un problème puisqu'une unique API permet de s'abstraire de l'environnement dans lequel on utilise l'application.
Si mon raisonnement etait erroné - càd qu'EGL est une couche à peine moins basse qu'OpenGL mais totalement indépendante de tout système de fenêtrage - il serait donc possible à X de s'appuyer dessus pour l'affichage mais le problème de l'absence de tranparence réseau impliquerait le développement d'une couche dans X pour le permettre ... on vient de réinventer GLX sauf qu'il s'appelerait EGLX \o/
Pour s'en convaincre, il suffit de comparer les specs de GLX et d'EGL ... elles se ressemblent beaucoup trop pour ne pas permettre les mêmes possibilités (la transparence réseau entre autre). En l'occurrence la même séparation entre un "état client" et un "état serveur" qui permet justement à GLX d'encapsuler les appels OpenGL dans le protocole X.
OpenGL/ES apparait effectivement comme étant une version pour embarqué d'OpenGL. Personnellement, je vois surtout une "remise à plat" d'OpenGL - ou plutôt une correspondance entre OpenGL/ES 1.0 et une version OpenGL 1.x donnée (je n'ai pas lu en profondeur les specs d'OpenGL/ES) - De plus, OpenGL/ES est montré comme étant une API 2D/3D totalement indépendante ... OpenGL l'est à l'origine (et ça doit remonter à IrisGL son ancêtre). D'ailleurs, pourquoi la libGL est-elle dans /usr/lib et non dans /usr/X11R6/lib ?
ayé, fini ^_^
ps: j'espère ne pas trop faire écho avec d'autres posts ... il y a presque 3h entre le début et la fin de mon roman /o\