J'ai envie de rebondir sur ce commentaire pour apporter ma petite pierre personnelle à cette discussion.
J'entend très souvent des gens se plaindre de X, pour toutes sortes de raisons, généralement mauvaises. Aurélien me pardonnera d'utiliser aussi les remarques qu'il m'a faites sur IRC :)
Je vais tenter d'expliquer l'origine des remarques, et pourquoi elles sont infondées.
1. X est lent parce qu'il utilise le réseau, même en local.
(On la voit moins ces derniers temps, c'est vrai.)
Des sockets sont utilisés pour le dialogue entre les applications et le serveur X. Cela a porté certaines personnes à penser que retirer le support réseau de X permettrait une avancée en termes de vitesse, parce que le réseau est une couche inutile pour une utilisation en local.
Mais voilà : en local, X utilise les sockets UNIX, qui sont une des formes les plus rapides d'IPC sous linux. Keith Packard (vous savez, le type qui innove dans X depuis bien longtemps et qui veut que ce soit rapide) avait comparé l'utilisation des sockets UNIX avec celle de la mémoire partagée pour le dialogue applis-serveur. C'était sans appel...
2. X est lent parce qu'il dessine lentement.
Vous déplacez une fenêtre et celles qui se trouvent en dessous peinent à se mettre à jour, vous voyez des trainées. Vous en concluez que X est lent pour afficher un pixmap.
Pour voir si l'affichage d'un pixmap à l'écran est vraiment lent chez vous, je vous propose de lancer x11perf -copypixwin500, qui va afficher à l'écran un pixmap de 500x500 et mesurer le temps que ça prend. Chez moi, c'est environ 2000 affichages par seconde. Ce n'est donc pas ça qui est lent. Faites d'autres tests de x11perf pour vous convaincre, si nécessaire. Vous devriez en conclure que X est rapide. Très rapide.
3. 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.
Par contre, c'est une API connue et maitrisée par de très nombreuses personnes et sensiblement identique pour tous les modèles de carte graphique, ce qui pourrait permettre un développement plus aisé. Faire du « Tout OpenGL » accélérera sans doute les effets spéciaux (transparence, déformation, exposé-like, ...), mais pas le reste. Ce qui sera accéléré par contre, c'est le développement sur une API connue.
4. X bouffe plein de RAM
Vous êtes gentiment connecté sur votre session X, et il vous vient tout à coup à l'idée de lancer un ps aux | grep X. Vous constatez alors que X utilise 285660 Ko, près de 280Mo. Woah !
Blâmez (si j'ose dire) votre soif d'avoir des applications ouvertes. Chaque application va demander au serveur X de lui allouer des pixmaps pour les fenêtres, les icones, les boutons, et plein d'autres choses. Tout ceci se retrouve compté pour X... Ajoutez à ça les zone de RAM vidéo qui sont mappées mais ne consomment pas de RAM système.
Vous pouvez faire le test très simplement (Note: Votre kilométrage peut varier, comme on dit.)
Toute instance de X étant fermée, faites un free -k dans une console et regardez la première valeur de la ligne +/- buffers/cache:. Elle vous indique la quantité de RAM réellement utilisée.
Dans une autre console, lancez juste X (pas startx ou xinit, juste X). Revenez sur la première console, relancez free -k et, ô miracle, X ne prend que 12 Mo ! Un examen attentif de la sortie de ps aux indique en outre que près de 10 Mo sont partagés. Pas très utile si vous n'avez qu'une session, mais intéressant pour ceux qui utilisent des terminaux distants. (Voir aussi le post de zero heure un peu plus bas.)
5. Le backing-store est la panacée, tout le monde doit l'utiliser
Ca commence à être possible, mais n'oubliez pas que si chaque fenêtre veut s'enregistrer dans le serveur X, le point 4 va recommencer à faire grincer des dents :)
Avec deux écrans, ma résolution est de 3648*1536, en 32bits. J'ai au strict minimum six bureaux remplis. Quantité de RAM nécessaire pour mettre tout ça en backing-store : 128Mo...
Le backing-store doit être utilisé là où il sera le plus utile, comme l'affichage d'images. Un mplayer ou une Konsole n'en ont pas besoin !
Mais alors pourquoi c'est lent ?
Principalement pour deux raisons.
La première, c'est que vos applications se redessinent lentement. Si je déplace une fenêtre à cheval sur le bureau (couleur unie), une konsole (fonte bitmap) et un konqueror, je n'ai des traînées qu'à un endroit : sur konqueror. Ici, le backing-store servirait bien.
La seconde raison, Aurélien l'a déjà évoquée : la xlib suce des huitres ! (mais non, c'est pas un troll)
Le protocole X est super, asynchrone, rapide... et la xlib est synchrone. Ça signifie que vos applis passent leur temps à attendre les réponses du serveur alors qu'elles pourraient s'en passer. Si ça se voit moins en local, c'est catastrophique dès que la latence grimpe un peu. XCB/XCL devraient permettre de corriger ce problème tout en gardant la compatibilité avec la xlib.
Je me permets une petite réflexion sous forme de questions pour terminer ce (trop) long post :
Pourquoi est-ce qu'à chaque troll sur Xorg (et avant lui, sur Xfree), ce sont les « mauvaises » critiques qui ressortent ?
Pourquoi personne ne s'étonne qu'il ne soit pas possible d'ajouter un écran à la volée, ou de passer d'un mode clone à un mode bureau étendu ?
Pourquoi faut il faire tant d'efforts pour brancher et configurer une tablette graphique ?
Pourquoi est-il tout simplement si complexe à configurer ?
[^] # Re: Cher Père Noël...
Posté par Amand Tihon (site web personnel) . En réponse à la dépêche X11R7.0 sous le sapin de Noël. Évalué à 10.
J'entend très souvent des gens se plaindre de X, pour toutes sortes de raisons, généralement mauvaises. Aurélien me pardonnera d'utiliser aussi les remarques qu'il m'a faites sur IRC :)
Je vais tenter d'expliquer l'origine des remarques, et pourquoi elles sont infondées.
1. X est lent parce qu'il utilise le réseau, même en local.
(On la voit moins ces derniers temps, c'est vrai.)
Des sockets sont utilisés pour le dialogue entre les applications et le serveur X. Cela a porté certaines personnes à penser que retirer le support réseau de X permettrait une avancée en termes de vitesse, parce que le réseau est une couche inutile pour une utilisation en local.
Mais voilà : en local, X utilise les sockets UNIX, qui sont une des formes les plus rapides d'IPC sous linux. Keith Packard (vous savez, le type qui innove dans X depuis bien longtemps et qui veut que ce soit rapide) avait comparé l'utilisation des sockets UNIX avec celle de la mémoire partagée pour le dialogue applis-serveur. C'était sans appel...
2. X est lent parce qu'il dessine lentement.
Vous déplacez une fenêtre et celles qui se trouvent en dessous peinent à se mettre à jour, vous voyez des trainées. Vous en concluez que X est lent pour afficher un pixmap.
Pour voir si l'affichage d'un pixmap à l'écran est vraiment lent chez vous, je vous propose de lancer x11perf -copypixwin500, qui va afficher à l'écran un pixmap de 500x500 et mesurer le temps que ça prend. Chez moi, c'est environ 2000 affichages par seconde. Ce n'est donc pas ça qui est lent. Faites d'autres tests de x11perf pour vous convaincre, si nécessaire. Vous devriez en conclure que X est rapide. Très rapide.
3. 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.
Par contre, c'est une API connue et maitrisée par de très nombreuses personnes et sensiblement identique pour tous les modèles de carte graphique, ce qui pourrait permettre un développement plus aisé. Faire du « Tout OpenGL » accélérera sans doute les effets spéciaux (transparence, déformation, exposé-like, ...), mais pas le reste. Ce qui sera accéléré par contre, c'est le développement sur une API connue.
4. X bouffe plein de RAM
Vous êtes gentiment connecté sur votre session X, et il vous vient tout à coup à l'idée de lancer un ps aux | grep X. Vous constatez alors que X utilise 285660 Ko, près de 280Mo. Woah !
Blâmez (si j'ose dire) votre soif d'avoir des applications ouvertes. Chaque application va demander au serveur X de lui allouer des pixmaps pour les fenêtres, les icones, les boutons, et plein d'autres choses. Tout ceci se retrouve compté pour X... Ajoutez à ça les zone de RAM vidéo qui sont mappées mais ne consomment pas de RAM système.
Vous pouvez faire le test très simplement (Note: Votre kilométrage peut varier, comme on dit.)
Toute instance de X étant fermée, faites un free -k dans une console et regardez la première valeur de la ligne +/- buffers/cache:. Elle vous indique la quantité de RAM réellement utilisée.
Dans une autre console, lancez juste X (pas startx ou xinit, juste X). Revenez sur la première console, relancez free -k et, ô miracle, X ne prend que 12 Mo ! Un examen attentif de la sortie de ps aux indique en outre que près de 10 Mo sont partagés. Pas très utile si vous n'avez qu'une session, mais intéressant pour ceux qui utilisent des terminaux distants. (Voir aussi le post de zero heure un peu plus bas.)
5. Le backing-store est la panacée, tout le monde doit l'utiliser
Ca commence à être possible, mais n'oubliez pas que si chaque fenêtre veut s'enregistrer dans le serveur X, le point 4 va recommencer à faire grincer des dents :)
Avec deux écrans, ma résolution est de 3648*1536, en 32bits. J'ai au strict minimum six bureaux remplis. Quantité de RAM nécessaire pour mettre tout ça en backing-store : 128Mo...
Le backing-store doit être utilisé là où il sera le plus utile, comme l'affichage d'images. Un mplayer ou une Konsole n'en ont pas besoin !
Mais alors pourquoi c'est lent ?
Principalement pour deux raisons.
La première, c'est que vos applications se redessinent lentement. Si je déplace une fenêtre à cheval sur le bureau (couleur unie), une konsole (fonte bitmap) et un konqueror, je n'ai des traînées qu'à un endroit : sur konqueror. Ici, le backing-store servirait bien.
La seconde raison, Aurélien l'a déjà évoquée : la xlib suce des huitres ! (mais non, c'est pas un troll)
Le protocole X est super, asynchrone, rapide... et la xlib est synchrone. Ça signifie que vos applis passent leur temps à attendre les réponses du serveur alors qu'elles pourraient s'en passer. Si ça se voit moins en local, c'est catastrophique dès que la latence grimpe un peu. XCB/XCL devraient permettre de corriger ce problème tout en gardant la compatibilité avec la xlib.
Je me permets une petite réflexion sous forme de questions pour terminer ce (trop) long post :
Pourquoi est-ce qu'à chaque troll sur Xorg (et avant lui, sur Xfree), ce sont les « mauvaises » critiques qui ressortent ?
Pourquoi personne ne s'étonne qu'il ne soit pas possible d'ajouter un écran à la volée, ou de passer d'un mode clone à un mode bureau étendu ?
Pourquoi faut il faire tant d'efforts pour brancher et configurer une tablette graphique ?
Pourquoi est-il tout simplement si complexe à configurer ?