Un étudiant anglais vient de publier "Y", un nouveau gestionnaire d'interface graphique, prétendant au remplacement du célèbre X.
Mark Thomas nous livre, en plus de son développement, un excellent document sur les gestionnaires d'interfaces graphiques et sur la conception de Y. X Window reçoit de plus en plus de critiques sur sa complexité de développement (hors toolkits), sa multiplicité des toolkits et sa relative lenteur, liée à un protocole réseau de très bas niveau.
Plusieurs projets ont été initiés pour remplacer X Window et proposer un nouveau gestionnaire graphique pour les systèmes Unix.
Aucun n'a pour l'instant atteint la taille critique qui le ferait apparaître comme une alternative crédible à X.
Y est donc un nouveau projet dans cette voie. Son initiateur, Mark Thomas, décrit dans son mémoire de fin d'études les faiblesses et forces actuelles de X Window et des interfaces de Windows et MacOS et jette ainsi les bases de Y.
Ces principes sont appliqués dans la première version du logiciel, disponible sur le site, mais l'absence d'applications et de pilotes accélérés n'en fait pas encore un produit réellement utilisable.
Aller plus loin
- Le document (pdf) (23 clics)
- La page du projet (79 clics)
- L'article sur OSNews (18 clics)
# Re: Après X, voici Y...
Posté par Amand Tihon (site web personnel) . Évalué à 10.
Pour ceux qui y croyaient encore, je rappelle qu'en local, X utilise les sockets Unix et la SHM, ce qui est la combinaison la plus rapide pour faire des IPC sous Linux (je ne m'avancerai pas pour les autres OS).
Ce qui pose problème, c'est l'implémentation actuelle de la Xlib et les applis. Le protocole X est asynchrone alors que la Xlib ne l'est pas toujours.
Si je me souviens bien, j'avais lu quelque part qu'un remplaçant en Lisp était en cours ou a l'étude, pour justement ne plus perdre ce mode asynchrone entre les applications et le serveur X.
De plus, il existe aussi au moins un "proxy" X qui fait de la compression/optimisation du protocole X pour accélérer tout ça : NX de Nomachine (http://www.nomachine.com(...) mais le site ne répond pas au moment où j'écris).
Bon, après mon coup de gueule, je vais quand même lire le pdf :)
[^] # Re: Après X, voici Y...
Posté par Obsidian . Évalué à 10.
D'autant que vouloir faire une alternative à X est intérressant pour le « progrès », mais si l'on veut faire quelque chose de propre, ce sera à mon avis aussi difficile que de réécrire un OS entier. Le remède ne serait-il pas pire que le mal ?
Ensuite, personnellement, je suis de ceux qui pensent que l'utilisation du bas-niveau est une bonne chose. Trop peu de personnes savent encore le faire aujourd'hui. L'utilisation d'une technique bien conçue écrite il y a 20 ou 30 ans (comme Unix en général) et fait à l'origine pour tourner sur des machines cadencées à l'ordre du mégahertz devient terriblement efficace sur des machines qui tournent 1000 fois plus vite.
D'autre part, je trouve la complexité de X toute relative mais surtout, je trouve son API très propre. L'agencement orienté objet de la chose est remarquable, surtout à une époque à l'Objective-C vient à la mode. Je donne souvent des exemples de programmation X à certains programmeurs débutants lorsque je veux qu'ils distinguent l'approche orientée objet elle-même des langages orientés objet.
Enfin, comme cela a été dit, pratiquement personne (et c'est bien dommage) n'utilise directement la X-Lib, tout le monde s'appuie sur des toolkits. C'est plus facile à la base, mais au bout du compte, la multiplication des couches finit par rendre la tâche d'interopérabilité aussi ardue que l'utilisation directe de la couche de base. Et surtout, cela devient également gourmand en ressources. Mon PC qui n'a pas encore 5 ans fonctionne sous Mandrake 9.1, et il faut 10 secondes entre le moment où X démarre et celui où KDM daigne enfin me proposer la boîte de login !
Alors Messieurs les développeurs, je n'ai qu'une seule requête à vous faire: Si vous souhaitez refaire le monde, soit, je vous accompagne, mais de grâce ne nous faites pas une nouvelle usine à gaz. On faisait il y a quelques temps le reproche aux logiciels de Redmond d'obliger les gens à upgrader trop souvent, et à envoyer au rebut des machines qui sentaient encore le plastique neuf, ou limite ! Ce serait dommage que Linux suive le même chemin.
[^] # Re: Après X, voici Y...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Et je rajoute que le protocole qui suit X11 est X12 pas y :)
X11 est extensible et il y a des études pour envoyer des objets lourds en format "standart" sans passer par des pixmap (image jpeg ou png décodé par le serveur et flux video également en format "natif").
Ce que j'avais vu d'étude de Xwin.org ou autre, c'était que X passait son temps à atteindre les applications (round trip inutile, etc...).
"La première sécurité est la liberté"
[^] # Re: Après X, voici Y...
Posté par gndl (site web personnel) . Évalué à 1.
J'ai un P200 MMX (j'y tiens au MMX :o) et l'affichage, bien que moins fluide que sous windows reste tout à fait acceptable.
Par contre j'ai du mal à croire que tu sois sérieux quand tu conseils d'utiliser la X-lib.
C'est complètement délirant d'envisager d'utiliser directement la X-lib pour une application moderne.
[^] # Re: Après X, voici Y...
Posté par Obsidian . Évalué à 1.
Ensuite "application moderne" me paraît légèrement ambigü ! Par exemple, même s'il existe certains packages pour le faire, je ne vais pas utiliser un toolkit particulier pour créer une DockApp !
Evidement, je ne vais pas me cantonner à la X-lib pour faire une interface utilisateur complète pour un logiciel, mais ce sera sutout pour:
- Eviter de réinventer la roue à chaque nouvelle application
- Utiliser l'environnement standard déjà employé par les autres applications.
Mais sûrement pas parce que c'est difficile de faire sans.
Au contraire: J'ai vu certaines personnes intégrer un toolkit dans leur application X simplement pour ouvrir une fenêtre, pour la seule raison qu'elles connaissaient mieux le prototype de la fonction de création de fenêtre du toolkit que celle de la X-lib (pourtant très proches). C'est du gâchis.
Le fait de passer 5 minutes à écrire proprement leur fonction en utilisant la X-lib permet de:
- s'affranchir d'un package
- s'affranchir de sa dépendence (et de son installation).
- s'affranchir de l'initialisation du toolkit
- libérer les ressources consommées par le toolkit, tant en
mémoire qu'en temps machine.
- s'assurer une compatibilité avec pratiquement tous les Unix.
Quand à ton P200 MMX, j'ai pour ma part fait tourner X sur un 486DX33 relié en réseau BNC 10Mbits à mon poste principal car j'avais besoin de faire de la saisie depuis une autre pièce. C'est une machine 8 fois moins rapide que ton P200MMX, mais il faut garder à l'esprit que c'est *énorme* pour un terminal.
Et je peux te garantir qu'il était très fluide. Du coup, j'ai justement tendance à penser que ta moindre fluidité par rapport à Windows était justement due à tout ce qui tournait au dessus, et pas à X-Window lui même. Sur mon PII/350Mhz la dernière Mandrake m'a fait passer à la nouvelle version de KDE, et il faut à présent plusieurs 10 de secondes pour ouvrir KMail, par exemple. Et effectivement, toutes les applis KDE ouvertes récentes sont « molles » sur ma machine. Par contre, les dockapps et WindowMaker en général sont en super forme ...
[^] # Re: Après X, voici Y...
Posté par puxor . Évalué à 10.
Rassure-toi, tu n'es pas le seul. Le pire, c'est que des gens arrivent à imaginer que tout ce qu'ils font sous X passe par le réseau (et il y en a!)
"Ce qui pose problème, c'est l'implémentation actuelle de la Xlib et les applis"
voire à ce propos la discussion très instructive lancée par Carsten Haitzler: http://sourceforge.net/mailarchive/forum.php?thread_id=1945128&(...)
au sujet de XCB (http://xcb.cs.pdx.edu(...)) un remplacement de Xlib.
[^] # Re: Après X, voici Y...
Posté par Misc (site web personnel) . Évalué à 3.
En gros, ça pourrait aller plus vite, avec un systéme un peu plus haut niveau, qui gererait des caches. Si j'ai faux, pas trop tapé, svp :)
[^] # Re: Après X, voici Y...
Posté par monseigneur . Évalué à 3.
Pas vraiment, le problème de buffer n'est réellement gênant que dans le cas d'une utilisation à distance. Lorsque l'on remet au premier plan une application, il faut la redessiner intégralement.
Selon l'auteur, le problème se situe plutôt dans le côté "bas niveau" du protocole de X Window.
[^] # Re: Après X, voici Y...
Posté par Stephane Chauveau . Évalué à 4.
La consequence la plus flagrante est que les redimensionnements opaque des fenetres ne sont pas fluide. Le WM recoit des dizaines ou meme des centaines de deplacement de souris chaque seconde.
A chaque fois, le WM redessine les bordures de la fenetre et envoit un message demandant a l'application de se redessiner.
Le probleme est que le scheduler a le choix entre 3 processus: Le serveur X, le WM et l'application.
Comme le server X et le WM sont actifs et que l'application ne l'est pas, le scheduler fait la navette entre X et le WM.
L'application obtient eventuellement la main apres quelques secondes.
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 2.
[^] # Re: Après X, voici Y...
Posté par Stephane Chauveau . Évalué à 1.
La solution la plus simple pour le WM consiste a limiter artificiellement le nombre de redimensionnement pas seconde.
Par example, j'ai obtenu de bon resultat avec Sawfish en ajoutant un usleep d'environ 40ms a la fin de la routine gerant les redimensionnements opaques.
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 1.
Cela fait longtemps que les toolkits gèrent ça très bien, après, certaines applis n'ont sans doute pas rattrapé leur retard, comme Konqueror.
Je peux redimensionner sans problème une appli comme Gnumeric ou Galeon et la mise à jour est instantanée, sans aucun artefact. Je pense que le double buffering de tous les widgets y est pour qqch.
Je pense que redimensionner un navigateur Web avec une page complexe est un des meilleurs exemples, et ça ne pose pas de problème chez moi, c'est fluide. Et je tourne en 1600x1200.
Je crois que la trop grande simplification du fonctionnement du scheduler de Linux est une des raisons qui fait que cette théorie n'est pas vrai tout le temps. Le problème peut aussi venir des drivers.
Et il ne faut pas croire que c'est la panacée ailleurs. Sur mon dernier portable, un Athlon 1400+, Windows a de gros problèmes de rafraîchissement comme ceux que tu décris (on voit carrément les carrés se déplacer parfois), alors que sous KDE ou Gnome sur la même machine, tout est plus fluide, et je n'ai pas ces problèmes. Et c'est une carte ATI sans accélération 3D sous Linux.
[^] # Re: Après X, voici Y...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Pour faire un bouton Qt ou gtk avec des angles arrondis, des dégradés, et tout et tout, il faut un bon paquet de primitives X11.
On pourrait au contraire imaginer un protocole d'un niveau plus élevé, ou le bouton en question serait dessiné par une seule primitive. Un truc avec plus ou moins une correspondance 1-1 entre les fonctions du toolkit et les primitives du protocol. Avec un truc comme ça, on pourrait faire de l'interface graphique jolie sur un reseau lent ...
L'autre intérêt serait d'encourrager l'utilisation des mêmes widgets pour toutes les librairies graphiques, un peu comme sous Windows : Les notions de menu, de bouton, de barre de défillement, ... sont des primitives win32, et la plupart des applications les utilisent, d'ou plus d'homogénéité. (Et pour ceux qui veulent une autre librairie graphique, mais qui les utilise quand même, il y a Qt, et sans doutes d'autres ...)
[^] # Re: Après X, voici Y...
Posté par - - . Évalué à 7.
pitié, ne pas croire que les "widgets" windows seraient une part de primitives graphique de windows
ce n'est qu'une couche par dessus gdi32 , de même que QT par dessus xlib
il n'y a rien de spécial
et on ne peut PAS imposer aux développeurs d'utiliser une SEULE toolkit
Xfree est fourni avec une toolkit , tant pis si les gens ne l'aiment plus
faudraient ils que Xfree deviennent GPL et qu'on fournisse GTK avec son archive pour que les gens croient que X a une nouvelle toolkit "intégrée" ? tss
sinon; on encourage tout le monde à utiliser soit gtk soit qt
on dirait que vous ne lisez pas les sites pro-kde ou pro-gnome ou les forums autour de X ou freedesktop, il y a des gens qui encouragent tout le monde à se fédérer sur une toolkit
il y a 2 toolkits de qualités qui vont fortement s'améliorer avec le temps : QT et GTK
et y a je ne sais combien de projets pour encourager l'usage que de ces 2 toolkits (des bindings, des "environnements", des papiers, des tutoriaux, etc)
bref, le travail se FAIT.
et "dessiner un bouton", c est pour tout système , l'appel de plusieurs primitives, et de manière ultime, pour la carte vidéo c'est une foule de pixels. on ne fait que déplacer le problème
X n'est PAS le problème !
ce sont les Applications, kde et gnome et les 2 toolkits qui sont à AMELIORER.
Ensuite, tout ce travail est caduque si on ne peut pas avoir de drivers vidéo qui permet à X d'utiliser pleinement la carte vidéo.
[^] # Re: Après X, voici Y...
Posté par monseigneur . Évalué à 2.
D'accord !
Mais le problème se trouve ici du côté des constructeurs !
Et pas qu'ils développent eux-même ! Non, ils doivent ouvrir leurs specs, c'est pas compliqué (et je ne vois pas vraiment quel avantage cela pourrait donner à leurs concurrents, qui doivent avoir bien d'autres moyens...)
[^] # Re: Après X, voici Y...
Posté par Obsidian . Évalué à 6.
Justement, l'une des « bonnes idées » que l'on pourrait reprendre est la création de « macros » coté serveur. On enverrait les primitives une fois, et on les rappellerait ensuite avec une seule séquence. Cela existe notament sur les serveurs de bases de données où l'overhead engendré par le parsing et le traitement d'une requête est beaucoup plus palpable.
Hors de la simple répétition, on pourrait envisager la construction d'une requête beaucoup plus sophistiquée comme par exemple le dessin d'un bouton (coin, bords, fond, légende, ...) et ne renvoyer que les coordonnées des coins pour que le serveur réadapte le même « contrat de phase » aux nouvelles dimensions ...
Tout cela implique, si ce n'est pas déjà disponible, une extension officielle du protocole. Par contre, on n'a probablement pas besoin de réécrire X pour cela.
[^] # Re: Après X, voici Y...
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
Finalement, avec Cairo (http://www.cairographics.org/(...)) et des macros, on ne serait plus très loin d'un Display PostScript :-P
[^] # Re: Après X, voici Y...
Posté par Jak . Évalué à 1.
L'utilisation d'OpenGL, ça pourrait servir à remplacer X-Render ou j'ai rien compris (je pencherais pour le n°2).
[^] # Re: Après X, voici Y...
Posté par Obsidian . Évalué à 1.
Ici, on constatait tout d'abord que le principal problème était qu'aussi puissant soit le toolkit utilisé au dessus de X, et même au dessus d'autres couches encore, il faudrait de toutes façons au final résoudre ses ordres en une quirielle de fondamentales X-window avant de transmettre cette dernière au serveur.
L'idée était donc d'optimiser la couche de base, et donc d'ajouter des fonctionnalités au serveur X pour qu'il soit nativement capable de faire les opérations les plus courantes en matière d'interface graphique (ici, dessin d'un bouton), et si cela implique des précisions explicites de la part du client, d'étendre le protocole pour tenir compte de ces nouvelles capacités. Attention, cela ne veut pas dire « implémenter un toolkit coté serveur » mais plutôt permettre de définir une seule fois un modèle particulier et ensuite le réappeler plutôt que le retransmettre.
L'objet du commentaire était de mettre en évidence le fait que l'API de X-Window semble suffisament bien conçue à la base pour permettre de telles extensions sans compromettre le système entier, et donc sans avoir à en réécrire un totalement nouveau.
[^] # Re: Après X, voici Y...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Il y a pourtant beaucoup de gens qui développent sous Windows, et peu de gens qui n'utilisent pas le toolkit par défaut (A part pour les lecteurs multimédia qui pensent tous que c'est bien de refaire le monde ...). Idem pour MacOS.
Je crois bien que c'est ce que propose le projet fresco aussi.
Je ne dis pas qu'il ne faut qu'une seule librairie graphique. Ce que je dis, c'est qu'au niveau du back-end, ca serait bien d'avoir des trucs de haut niveau et qu'on soit encourragés à les utiliser. Bien sur que pour ta carte graphique, il y aura toujours pleins de pixels dans ton bouton, mais au niveau communication inter-processus, ou est la nécéssité de faire autants d'appels différents ?
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 2.
Et puis honetement pour une utilisation desktop, tout le monde n'as pas besoin des fonctions reseau de X11 ( on peux alors passé par du XonX )
[^] # Re: Après X, voici Y...
Posté par _alex . Évalué à 3.
(Et si la carte ne fait que 2D, rien n'empêche d'emuler ce procédé)
NB: Et vu que les dernières CG sont des monstres de calcul, on pourrait presque implémenter chaque widget (comme les boutons) comme des textures avec pixel/vertex shader/etc pour faire les ombres/transparence. Le tout ne couterait rien au CPU ou presque...
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 1.
Ca doit être une des raisons pour laquelle l'interface de Mac OS X est si lente dans pas mal de cas. En tout cas, cela dépend de bons drivers 3D ou 2D, et c'est une idée intéressante, mais pas pour le réseau, à mon avis. X redessine ses fenêtres, et il est utilisé depuis 15 ans, et les machines de l'époque n'étaient pas des foudres de guerre. Je ne pense pas que Quartz fonctionne avec des machines d'il y a 15 ans.
NB: Et vu que les dernières CG sont des monstres de calcul, on pourrait presque implémenter chaque widget (comme les boutons) comme des textures avec pixel/vertex shader/etc pour faire les ombres/transparence. Le tout ne couterait rien au CPU ou presque...
Il reste juste le problème de la bande passante et de la taille mémoire ...
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 1.
[^] # Re: Après X, voici Y...
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
Bon c'est un ibook2 avec Ati Rage 128, donc pas de Quartz Extrem hein.
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 1.
Et c'est justement ce que j'aimerais avoir sous linux. Quand on voit les possibilité ca fait réver. Aucun des projet alternatifs ( DirectFB, Y, Fresco, Xouvert, ect...) ne semble aller dans cette direction. Il serait grand temps ( s'est mon avis hein ) que Linux se dote d'un systeme d'affichage de nouvelle génération. Comme d'ab Apple à lancé le mouvement, Microsoft est en train de suivre et Linux est à la traine. Après on se demande pourquoi linux est à la traine niveau desktop, simplement le desktop sous linux n'obtient pas assez de considération. Quand je vois le nombre allucinant d'utilisateur Linux qui essai de se faire un bureau a-la-MacOSX (Décoration de la fenetre, icones, SuperKaramba/Kroller ou l'équivalent gnome dont je ne me rappel pas le nom) !
Je ne reproche pas a x11 d'etre ce qu'il est (c'est vrai c'est genial le x11 fowarding sous ssh, c'est genial les terminaux X), simplement je pense qu'il a fait son temps. Et ce n'est pas en rajoutant une extention pour gérer completement le canal alpha que ca fait fera l'affair. Comme dirait les politiciens, il faut "une reforme de structure".
Si j'avais les co**lles pour lancer un tel projet, je le ferait.
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 1.
C'est faux, il y a Cairo, et Keith P. fait partie du projet, c'est lié à Xouvert je crois. Et ca n'a rien d'une panacée, ce sera encore une extension à XFree. Et tu as l'air de dire que XFree n'est pas de dernière génération. Ses extensions lui permettent de rester toujours à jour, au contraire.
Et si les utilisateurs Linux se font un bureau à la MacOS X, c'est parce qu'ils peuvent le faire, ce qui me paraît assez impressionnant. S'ils le font, je suppose que c'est parce que cela leur plaît.
Et il faut arrêter de dire n'importe quoi, XFree gère le canal Alpha depuis très longtemps. Son problème n'est pas la gestion du canal Alpha, parce qu'au cas où tu ne le saurais pas, les fenêtres translucides, cela existe depuis très longtemps sous XFree. Le problème, c'est que les applications n'ont pas connaissance de chacune d'entre elles. Ceci a été fait dans un but de sécurité !
Avant de vouloir réformer tout et n'importe quoi, il faudrait comprendre déjà les problèmes.
XFree a certains problèmes qui ont été identifiés et peuvent être résolus sans casser la compatibilité des applis.
Le peu de connaisseurs en interface graphique dans le monde libre y travaillent durant leur temps libre, mais ce n'est pas trivial.
SI ta réforme de structure concernait ce fait, alors oui, il en faut une, et elle est en cours.
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 1.
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 1.
Et je te répète que le canal Alpha est géré. Si mon exemple ne t'a pas convaincu, je t'en donne d'autres (que j'ai déjà donnés sans le dire) : la souris transparente, les menus transparents.
Le seul problème, c'est que si l'on voulait que ça affiche en fonction de ce qu'il y a dessous, il faudrait transférer trop de données avec le design actuel. C'est uniquement un problème d'efficacité avec le X actuel, et pas dû au fait que ce n'est pas implémenté.
C'est la raison pour laquelle les fenêtres avec background transparent dont tu parles, bien qu'elles soient réellement transparentes, ne prennent en compte que le fond d'écran, il me semblait l'avoir dit.
Après, que tu veuilles que ça marche, je suis d'accord avec toi.
Que ce soit une fonctionnalité nécessaire, je ne suis pas du tout d'accord, ce n'est que de l'Eye Candy et ne sert strictement à rien.
Mais je crois que cela fonctionne sous MacOS X. Donc si c'est si important pour toi, et que tu ne peux pas attendre que ce soit implémenté (il me semble que c'est en cours, et lié à Cairo, mais pas avant 3-5 ans amha), tu vois ce qu'il te reste à faire ;)
[^] # Re: Après X, voici Y...
Posté par Guillaume Maillard (site web personnel) . Évalué à 1.
Pb de securite... J'ai l'impression que pour toi, gerer la transparence dans une fenetre, c'est avoir acces aux bitmaps des fenetres en dessous pour pouvoir calculer la superposition avec les canaux alpha... effectivement ca ne serait pas 'secure'.
C'est au server a gerer la transparence, c'est a lui de faire de faire les calculs qui vont bien pour que quand une appli fait trace qq chose, le resultat a l'ecran respecte les canaux alpha.
Avec la Xlib point de canaux alpha.... avec XRender c'est possible mais ca rame enormement. ( suffit de regarder le code source des drivers pour voir qu'il n'y a pas de support de l'alpha )
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 1.
Et puis un mac je t'ais pas attendu pour en acheter un !!! Et il est possible de faire tourner linux meme sur un mac...et bien que ce soit eye candy, il n'y a pas que ca...il y a aussi des question d'érgonomie : par exemple avoir la transparence activé sur toutes les fenetres qui n'ont pas le focus permet de voir leur contenu et donc de pouvoir les retrouver facilement par exemple. Et si pour toi une interface graphique ne se limite qu'a des fenetre c'est sur que ca "ne sert strictement à rien".
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 1.
Le design actuel.....enfin non finalement je crois que je ne vais rien ajouter, dans cette phrase tu as tout dis....
[^] # Re: Après X, voici Y...
Posté par dinomasque . Évalué à 3.
Lisez donc ça, c'est très intéressant et plein de vrais chiffres concrets :
http://osnews.com/story.php?news_id=1905(...)
BeOS le faisait il y a 20 ans !
[^] # Re: Après X, voici Y...
Posté par Beretta_Vexee . Évalué à 3.
[^] # Re: Après X, voici Y...
Posté par Guillaume Maillard (site web personnel) . Évalué à 1.
Voila un autre mythe!! Il n'y a pas 5% des applis qui utilisent SHM. SHM perment de partager des bitmaps entre le client et le serveur sans le transferer par socket. MAIS il faut explicitement utiliser l'API de SHM pour ca, une appli non designe pour utiliser SHM ne le ferra pas (meme inconsciement).
Ecrire des tonnes d'extension pour XFree ne sert a rien car quel developpeur vas redesigner son applis tous les 2 ans pour rajouter partout des tests genre:
si SHM est dispo et je suis en 'local' alors je l'utilise
si XRender est dispo et est accelere en hard alors je l'utilise
etc etc....
Les problemes de X sont exposes ici:
http://www.osnews.com/story.php?news_id=1905(...)
Cote perf, meme sans utiliser autre chose que du Xlib pur, les applis pourraient etre rapides, mais ca demande enormement de temps. Sous B.E.OS (www.BlueEyedOS.com), le pari a ete pris de faire ces optimisations cote server d'application du systeme. Du coup toutes les applications utilisant l'API de B.E.OS (qui est la meme que celle de BeOS) beneficient de toutes les accelerations possible cote serveur.
[^] # Re: Après X, voici Y...
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
Oui, mais bon la plupart des applis actuelles utilisent un toolkit et pas la xlib de base ! j'ose espérer que ces toolkits supportent la shm ? en tout cas, c'est le cas avec le backend art pour GNUstep :-P et de toute façon, c'est un problème côté toolkit là, pas côté application !
idem pour tes remarques sur les extensions : ça concerne le toolkit, pas l'appli. Donc on fait ça qu'une fois et on impacte les applis utilisant le toolkit, ça vaut le coup non ? La quasi-totalité des applis récents graphiques utilisent soit Qt, soit Gtk, ça ne fait que deux toolkits à modifier hein ...
# Re: Après X, voici Y...
Posté par Pierre Pronchery (site web personnel) . Évalué à 10.
Je n'ai pas encore retrouve son papier mais le sujet est aborde ici: http://osnews.com/story.php?news_id=1905(...)
khorben
[^] # Re: Après X, voici Y...
Posté par Vincent Richard (site web personnel) . Évalué à 10.
Ca ne serait pas cet article par hasard ?
http://linux.tlk.fr/articles/xfree86_accelerer.php(...)
# Re: Après X, voici Y...
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Après X, voici Y...
Posté par JSL . Évalué à 1.
http://mail.gnu.org/archive/html/xouvert-general/2003-09/msg00192.h(...)
(en gros, il y a des idées à creuser, mais X restera X, même et surtout chez Xouvert)
# Re: Après X, voici Y...
Posté par mammique . Évalué à 7.
http://sourceforge.net/projects/xonx(...)
http://www.fresco.org/(...)
[^] # Re: Après X, voici Y...
Posté par Amand Tihon (site web personnel) . Évalué à 10.
Un autre point : trop souvent, ce qui fait s'effondrer les perfs, c'est que lors du déplacement d'une fenêtre, le serveur X envoie des centaines d'événements Expose aux applications qui se trouvaient en dessous, pour qu'elles redessinent un morceau de leur fenêtre. La solution est facile à comprendre mais plus ardue à mettre en oeuvre :
- soit on a un BackingStore (presque plus besoin d'Expose, le serveur connaît le contenu de chaque fenêtre)
- soit le serveur X "regroupe" les différents Expose dans la queue d'événements. Cela dit, il le fait peut-être déjà. Si c'est le cas, c'est parce que X est trop rapide qu'il est lent, ou du moins en donne l'impression :)
Le backingStore a aussi d'autres « avantages » : il permet la vraie semi-transparence. Avant qu'on me hurle dessus, je signale que je n'aime pas avoir ça sur l'entièreté d'une fenêtre normale. Mais ça permettrait de gérer les ombres des fenêtres (kde 3.2 roxor :p), des menus, et éventuellement, rendre semi-transparente une fenêtre lors de son déplacement. Tout ça bien sûr sans rien ralentir, n'importe quelle carte depuis la TNT1 étant capable de le faire en hardware.
Et lors du mode réseau, le fait que le serveur garde en mémoire l'image de la fenêtre évite de devoir redemander à l'application de se redessiner alors que la liaison passe par une ligne satellite avec une latence d'une seconde...
Donc non, je ne pense pas que X soit vieillissant. Tout au plus, c'est l'implémentation offerte par XFree et la Xlib qui n'est pas complète/parfaite. Je suis quasi certain que l'utilisation du backingStore et d'un backend OpenGL, couplée à une gestion un rien différente des Expose offrirait quelque chose de très très bon.
[^] # Re: Après X, voici Y...
Posté par Beretta_Vexee . Évalué à 4.
De plus quand l'on voit des intrafaces comme Aqua, ou les demos de celle de Longhorn, on a de quoi se faire du soussit quand a X, qui ne gére pas l'alpha blending, alors que la concurence va integrer les transformations 3D.
[^] # Re: Après X, voici Y...
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
> Longhorn, on a de quoi se faire du soussit quand a X, qui ne gére pas l'alpha
> blending, alors que la concurence va integrer les transformations 3D.
Tu pourrais nous en dire plus ? J'ai jamais vu Aqua de près et je ne sais pas ce que fera longhorn ...
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 0.
Peux-tu expliquer ?
Parce qu'il me semblait à moi, que XFree définissait maintenant le standard X11, au contraire de ce que tu dis !
Et je ne vois pas où XFree s'est écarté du standard X11 : donne un exemple, merci.
XFree a plus de 15 ans, et il est encore compatible avec toutes les applications d'il y a 15 ans.
Effectivement, des héritages de X sont encombrants : le fait qu'il ne soit pas asynchrone partout, et le fait qu'il ne favorise pas les latences faibles (la réactivité). Ou encore, le fait que les objets ne puissent pas avoir de relations plus poussées au sein du serveur.
De plus quand l'on voit des intrafaces comme Aqua, ou les demos de celle de Longhorn, on a de quoi se faire du soussit quand a X, qui ne gére pas l'alpha blending, alors que la concurence va integrer les transformations 3D.
Allo ?
Peux-tu éviter de mélanger pommes et oranges ? En quoi les interfaces ont quelque chose à voir avec X ? X n'a PAS d'interface (enfin, de toolkit). Tu voulais surement comparer à Gnome ou KDE, auquel cas, on est totalement hors sujet.
[^] # Re: Après X, voici Y...
Posté par gndl (site web personnel) . Évalué à 1.
Non, il n'est pas hors sujet. Les toolkits utilisent les primitive graphiques fournies par X au travers de la Xlib. Si on veut fournir à nos interfaces de la transparence et des effets 3D, la façon la plus efficace de le faire est d'utiliser les capacitées des cartes graphiques. Hors c'est X qui attaque les cartes (c'est lui qui possède les drivers). Les toolkits sont des bibliothèques de haut niveau qui n'ont pas à exploiter directement les cartes graphiques. La Xlib doit donc fournir la transparence et les effets 3D.
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 1.
La transparence ? Elle est déjà dans XFree depuis longtemps, en utilisant les capacités des cartes graphiques (mais ça, c'est un problème de driver).
La 3D ? La Xlib ne fournit pas les effets 3D, mais fournit les canevas. Et on utilise OpenGL pour dessiner en 3D dans ces canevas. Et avec des extensions de XFree, on peut a même des primitives accélérées qui gèrent cela.
Donc il n'y a rien à faire à ce niveau.
Ceci dit, X n'a toujours pas de toolkit, il a été créé de façon à pouvoir accepter n'importe lequel.
Une des choses qui manque à XFree, pour pouvoir amener de l'Eye Candy qui ne sert à rien, c'est la communication entre les clients au niveau graphique, pour pouvoir avoir la transparence entre fenêtres, car sinon, les fenêtres (les principales) n'ont aucune idée de l'existence des autres. C'est pourquoi la transparence n'est toujours implémentée que par rapport au fond d'écran. DBus, qui permettra la communication au niveau des WM je crois, doit permettre de régler ce "problème". Je ne pense pas que ce sera fait au niveau du serveur X. Ca demandera plus de bande passante, évidemment.
[^] # Re: Après X, voici Y...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
J'avais vu passé un site web, sur dlfp, il y a qq mois qui expliquait comment l'utiliser.
Le pb d'opengl est que toutes les machines par très puissante en sont exclu. De plus, quand on voit le support d'accélération 3D libre...
"La première sécurité est la liberté"
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 1.
Je trouve pas que ce soit un pb, si tu n'as pas de carte acceleratrice openGL alors tu ne sera pas acceleré et marchera donc en software...de plus ici je pense qu'on parle + de 2d que de 3d...
# [HS] X, Y... Z ??? enfin B ?????
Posté par Baptiste SIMON (site web personnel) . Évalué à 0.
A voir l'évolution expliquée dans cette news, je prends peur ! J'aime beaucoup X, je trouve qu'une nouvelle initiative (Y) pourrait etre intéressante... mais je souci, c'est que la prochaine étape, c'est Z... dont le successeur est B (comme dirait un de mes anciens profs (je garderais mes commentaires pour moi, de manière à rester un minimum respectueux), Mr Habrias, "c'est parce que B, c'est avant-C"), le super langage/méthode/etc... de spécification formelle développée par un je-sais-plus-qui (que mes études m'ont fait détester) avec lequel a été spécifié (et programmé ?) les lignes de métro totalement automatisées...
Bref, attention aux dérives ;c)
Je ne conseille à personne de finir comme HH !!
PS: les nantais étant passés à l'IUT de Nantes, à la fac d'info voire mm peut-etre à polytech comprendront... ;c)
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par Infernal Quack (site web personnel) . Évalué à -1.
B puxor !!!!!!!
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par vieuxshell (site web personnel) . Évalué à 1.
Le B c'est Bien, l'utiliser ca craint.
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par tuiu pol . Évalué à 1.
Perso j'ai bien aime :)
Ps: tu es de quelle promo Vieuxshell ?
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
J. R. Abrial ?
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par Anaximandre . Évalué à 3.
C'est vrai que faire des insinuations sur ton prof, tout en te gardant des insultes, c'est vachement respectueux.
"c'est parce que B, c'est avant-C"
C'est surtout parce que Z c'était une allusion à ZF (la théorie axiomatique des ensembles de Zermelo-Fränkel), et que B est une allusion à Nicolas Bourbaki, le mathématicien polycéphale auteur des Éléments de mathématique.
le super langage/méthode/etc... de spécification formelle développée par un je-sais-plus-qui (que mes études m'ont fait détester) avec lequel a été spécifié (et programmé ?) les lignes de métro totalement automatisées...
Je ne suis pas fan du B, mais il faudrait peut-être connaître un peu plus que ce que tu as appris en cours pour avoir les moyens de critiquer. Le B sert (et a été utilisé avec succès) dans le développement d'applications critiques. Ça reste néanmoins un outil proche du monde de la recherche, et il est évidemment hors de question que ce soit utilisé à grande échelle actuellement, mais ses descendants se trouveront peut-être un jour en entreprise (quoique j'en doute, la théorie intuitionniste des types me semblant posséder un meilleur potentiel à terme).
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par let antibarbie = xp <- xp - 1 . Évalué à 1.
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par Anaximandre . Évalué à 1.
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par Anaximandre . Évalué à 1.
Il ne s'agit pas ici de polémiquer, mais bien de poser cette question d'un point de vue scientifique: y a-t-il une différence réelle entre un problème industriel et un problème mathématique, du point de vue de la difficulté intellectuelle de la tâche? Je n'en suis pas sûr.
D'un point de vue formel, un problème d'ordonnancement (par exemple) ou un problème de maths, c'est kif-kif: c'est juste une chaîne de caractère (dotée d'une sémantique), qui est censée représenter ton problème, et sur laquelle tu effectues un certain nombre de preuves de propriétés.
L'équipe de logique de Nijmegen a ainsi formalisé et certifié en Coq le théorème de d'Alembert-Gauss, ce qui n'est pas plus simple que des problèmes industriels de petite taille.
Et c'est là qu'on peut dire par contre, qu'un problème industriel a la fâcheuse manie d'être de très grande taille, sans être forcément compliqué, d'un point de vue intuitif.
Un gros challenge pour les méthodes formelles consiste donc certainement à un saut «in the large», ce qui est très difficile pour des raisons techniques (explosion du graphe d'états). L'automatisation croissante des outils formels va dans le bon sens, mais il y a encore beaucoup de boulot.
Ce qui fait l'intérêt de la recherche: on va pas reprocher à l'équipe Coq de faire des recherches, c'est son boulot et il y a matière à recherche!
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par toBfree . Évalué à 0.
b) ça fait des années que Coq est «prometteur»
c) ça fait maintenant des années que METEOR tourne
La taille et la complexité ne sont pas des notions interchangeables par la seule volonté de ton intuition. Elles déterminent des domaines d'applications qui ne sont pas perméables. B a été conçu *pour* ce type de problèmes, ce n'est pas le cas pour Coq.
Ceci dit, tentons de revenir à nos moutons... ;-)
«Un gros challenge pour les méthodes formelles consiste donc certainement à un saut in the large» ...
C'est déjà le cas pour B, et peut-être même que cela pourra se faire avec des outils libres !!!
http://savannah.nongnu.org/projects/brillant/(...)
Les outils en cours de développement sont en Java mais aussi (surtout) en ... OCaml !! ;-)
Par exemple, un prouveur expérimental dénommé BPhox est en cours de réalisation. Il utilise Phox une sorte de version allégée de ... Coq !! ;-)
La boucle est bouclée. Tout le monde est content
Il y a encore beaucoup de boulot. Des volontaires ?
En particulier les outils n'ont pas d'interface ... X
:o)
Cordialement
[^] # Re: [HS] X, Y... Z ??? enfin B ?????
Posté par Anaximandre . Évalué à 0.
a) ça fait des années que B est utilisé en milieu industriel
c) ça fait maintenant des années que METEOR tourne
N'en rajoute pas tout de même, ce n'est pas encore la consécration. Il y a eu un développement marquant (le système de freinage de METEOR) mais pas grand-chose depuis.
b) ça fait des années que Coq est «prometteur»
Rappelons tout de même que la théorie axiomatique des ensembles date de 1910-1920 alors que la théorie des types a réellement débuté en 1971 (Martin-Löf). Il reste beaucoup de choses à construire, d'autant plus que la théorie des types est plus complexe que la théorie des ensembles (notamment à cause du manque d'extensionnalité).
J'ajoute que B est lui aussi encore en développement: B événementiel, mais aussi définitions inductives (un des derniers dadas d'Abrial) de structures complexes (au lieu d'en rester à certains types de données prédéfinis), etc.
La taille et la complexité ne sont pas des notions interchangeables par la seule volonté de ton intuition.
Je ne crois pas avoir écrit cela mais : «y a-t-il une différence réelle entre un problème industriel et un problème mathématique, du point de vue de la difficulté intellectuelle de la tâche? Je n'en suis pas sûr.» D'un point de vue formel, spécifier un problème de maths ou plus orienté systèmes, c'est pas vraiment différent.
Elles déterminent des domaines d'applications qui ne sont pas perméables. B a été conçu *pour* ce type de problèmes, ce n'est pas le cas pour Coq.
Effectivement, B est orienté systèmes, surtout avec son procédé de raffinement jusqu'au B0. Et Coq est généraliste dans l'absolu, même si les développements marquants sont en maths formelles. On a quand même les types coïnductifs et l'extraction de code, de même que l'annotation de programmes impératifs (à la Floyd-Hoare et... B).
C'est déjà le cas pour B
Là je ne suis pas d'accord: même pour B ce n'est pas le cas. Le système de freinage de METEOR fait environ 60.000 lignes d'Ada (Abrial dixit) si mes souvenirs sont bons. On est loin d'un programme industriel de plusieurs millions de lignes.
http://savannah.nongnu.org/projects/brillant/(...(...))
Les outils en cours de développement sont en Java mais aussi (surtout) en ... OCaml !! ;-) Par exemple, un prouveur expérimental dénommé BPhox est en cours de réalisation. Il utilise Phox une sorte de version allégée de ... Coq
C'est rigolo mais parmi les participants, je connais un chargé de recherche (collègue de bureau) qui utilisait Coq pour prouver du B parce que l'Atelier B n'est pas assez puissant!
Quant à PhoX, ce n'est pas un Coq light. C'est un assistant fondé sur la logique classique d'ordre supérieur (implémentée en AF2), pas du tout sur le calcul des constructions inductives, qui est en plus intuitionniste. Cela dit, PhoX est vraiment très agréable à utiliser et très «pragmatique».
# Re: Après X, voici Y...
Posté par vincent LECOQ (site web personnel) . Évalué à 1.
cela dit le problème n'est pas la, X en lui même est très bien fait et, dans la mesure des spécifications de cartes disponibles, très rapide. c'est du coté des apps qu'il faut voir le problème.
cependant, le protocole X pourrait être mieux organisé, surtout sur le refresh d'une fenetre. un bon exemple est BeFree il me semble, la différence de gestion entre X et BeFree est surprenante, surtout sur de petites configurations.
[^] # Re: Après X, voici Y...
Posté par reno . Évalué à 1.
Fresco et Berlin, c'est la même chose, Berlin s'est renommé en Fresco, il explique pourquoi il n'aime pas Fresco: la complexité de la chose, la lourdeur de CORBA..
Je comprends son points de vue sur Fresco, mais pour le moment je n'ai pas bien compris pourquoi, il avait fait Y a la place de contribuer a PicoGUI, qui m'a l'air d'etre tres semblable pour le concept
Ceci dit, je n'ai pas encore fini de lire son PDF..
Au fait, c'est quoi BeFree? BeOS je connais (requiesca en pace), mais pas BeFree..
# Re: Après X, voici Y...
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 5.
Ce que je sais par contre, c'est que la plupart des interfaces que je vois tourner sous linux sont souvent assez molle en face de la même config et la meme appli sous windows.
Par exemple, il y a quelque chose qui m'enerve un peu en ce moment : la réactivité de firebird sous linux par rapport à la version windows... (les tabs sont beaucoup plus lent sous linux... En particulier quand une page se charge en background)
Je pense donc que ce document est important. Je ne serai pas capable de dire si son étude est correcte en ce qui concerne Y, mais au moins il permet de relancer le débat (toll?). La chose dont je suis sur, c'est qu'il est très certainement possible d'avoir mieux que l'actuel... Il suffit de comparer les interfaces graphiques des autres plateformes pour s'en rendre compte.
Perso, linux est mon environement favori... Et je fais donc pas attention à ce genre de petits désagrément puisque tout le reste rattrape. Mais je pense que pour tous les cliqueurs fous qui sont habitués à d'autres OS, doivent vite remarquer le temps de réactivité différent.
[^] # Re: Après X, voici Y...
Posté par Mickael_83 . Évalué à 1.
Mais je pense que quelque part ceci est un faux débat.
N'oublions pas que X n'est qu'une couche graphique de Linux, et que linux n'a JAMAIS été particulièrement optimisé pour supporter une interface graphique. Linux et son kernel sont conçus pour faire tourner des tas d'applics en mode multitâche,sans saturer le sytème, et ce très rapidement: les serveurs web, ftp, ssh, mysql, postgress SQL, etc, etc....
Au contraire de Windows qui lui est codé autour d'une interface graphique, et c'est là son problème: n'importe quel codeur, admin, geek ou neird te le dira, il est impossible de tout faire tourner correctement à partir de l'interface graphique, tout comme il est impossible d'assurer une taux de fonctionnement stable à 100% de celle-ci. X-Window est un outil de linux, un composant supplémentaire, et on peut très bien se servir de Linux sans se servir de X.
Certes, on pourrait l'optimiser, améliorer sa réactivité, mais à ce niveau là il faudrait sans doute inclure ces améliorations au niveau du kernel. Sauf que là, on tomberait dans le même piège que la firme de Redmond: on développerait un noyau autour d'une interface, et non l'inverse, avec tout ce que cela apporte de dramatique. Si Bilou avait effectué les même choix que Linus, alors peut-être que Win serait un concurrent crédible pour nos pingouins. Mais il ne l'a pas fait et aujourd'hui M$ est prisonnier d'un mauvais choix tactique (IE qui plante, l'explorateur, active desk and co...)
Alors perso moi je dis non, que X reste ce qu'il est, un outil optionnel, même s'il n'est pas parfait, et surtout qu'il ne vienne pas interférer sur la puissance de nos bastions et de nos serveurs.
Après, il reste plusieurs solutions pour optimiser le fonctionnement sous X: soit avoir une distro spéciale GUI avec toutes les options possibles, et ça je sais pas si ça existe pas déjà, soit, et là c'est beaucoup plus lourd, recompiler par vous même votre propre X ainsi que toutes les applics qui vont avec: prévoyez donc des Gigas d'espace libre, récupérez toutes les sources, optimisez, réglez, compilez et partez en vacances quelques semaines, le temps nécessaire à la compile... Je sais, ça fait long, c'est lourd, mais ça doit pas mal pousser au final, si vous vous en sorter à la compile.... :-)
[^] # Re: Après X, voici Y...
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 2.
Il se trouve que moi aussi je possède un PC à 1GHz et que justement je m'apercois que les programmes windows sont plus rapide que ceux qui tournent sur mon X. Ensuite, j'ai une gentoo, donc je recompile absolument tout les programmes, et j'essaye pour chacun de les configurer avec les meilleurs flags... Et résultat : la vitesse est exactement la même que lorsque j'avais Debian (En tout cas, je ne me suis pas apercu d'un gain de rapidité)... Donc, la recompilation ne changera absolument rien.
Et finalement je pense qu'il faut toujours, comme aujourd'hui, bien différencier le noyau et la couche graphique comme tu le soulignes... C'est évident... Personne ne remet ca en cause.
Par contre, il faut bien que les choses s'améliorent non ? Quand je lis ton message, j'ai l'impression que tout va bien, qu'il ne faut rien toucher... Et là dessus je ne suis pas d'accord. A mon avis c'est en se remettant toujours en question que l'on fait avancer les choses et que ca s'améliore. Dans ce cas précis, on est à peu près tous d'accords que les interfaces sous linux sont globalement moins réactive que chez les concurents... Et qu'il faut trouver un moyen pour l'améliorer... C'est tout.
Après que ca vienne de X, de GTK ou de Qt moi j'en sais rien... Ce que je voulais dire dans mon post pécédent, c'était que j'étais content qu'il y ai des documents de ce genre publiés pour relancer les débats et les idées sur les améliorations à apporter.
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 1.
Non, la recompilation ne changera rien. Ce n'est pas un problème de rapidité de X, c'est uniquement un problème de rapidité de toolkit, de driver, et aussi un problème de l'utilisateur (pour les préférences du gestionnaire de fenêtres) .
Tu dis que tes programmes sont plus rapides sous Windows que sous Linux ? Mais déjà, la phrase ne veut rien dire. Moi-même, je serai bien incapable de faire une telle comparaison. Déjà, parce que j'ai très peu d'applis en commun entre Windows et Linux.
Je ne vois pas quel programme serait plus rapide dans une interface graphique non plus. Si tu veux parler de réactivité, il faudrait déjà comparer ce qui est comparable. Remet ton window manager au niveau de Windows, tu vas voir que c'est extrêmement rapide.
Après que ca vienne de X, de GTK ou de Qt moi j'en sais rien
Il est bien là le problème, tu ne sais pas de quoi il est question, mais tu dis que c'est bien malgré cela. Les problèmes que tu as n'ont rien à voir avec X (juste un peu à voir avec XLib), et plutôt à voir avec ton toolkit ou la manière dont il est configuré.
Redescend ton Gnome ou ton KDE au niveau d'un Windows (c'est-à-dire, enlève pratiquement tout et laisse les thèmes gris tous simples), et tu vas voir que ça va tout aussi vite, même plus vite que sous Windows (niveau réactivité, pour bien comprendre de quoi l'on parle, et je crois que c'est de ça dont tu parles).
[^] # Re: Après X, voici Y...
Posté par Nicolas Antoniazzi (site web personnel) . Évalué à 0.
Bien sur c'est vrai que je ne m'appui sur aucun chiffre ou bench pour prétendre ça. C'est juste le sentiment que j'ai pendant l'utilisation... Et de toute façon, je ne suis pas le seul à le remarquer.
Le problème que j'ai avec ton message, c'est que j'ai l'impression de me faire agresser parce que je dis que sous windows c'est plus réactif... Bein en tout cas moi, c'est le sentiment que j'ai et j'attend avec impatience que ca s'améliore sous linux puisque je l'utilise tous les jours... Voilà, ca va pas plus loin... Je ne suis pas un admirateur de microsoft, au contraire, mais je reconnais que en ce qui concerne la réactivité de l'interface, c'est plus rapide.
Ensuite, je n'utilise ni Gnome, ni KDE mais Enlightenement... Et mon theme est très léger donc je ne pense pas que cela soit la source du problème...
Et finalement je donne mon impression d'utilisateur... Comme tu le dis je parle de choses que je ne maitrise pas... Seulement des sensation que cela me procure.
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 1.
Le pb avec les geek c'est le "sentiment que tu as pendant l'utilisation" ils ne comprennent pas ;)
Tu as pas un algo pour ce sentiment, tu pourais pas me hacker ca en C que tout le monde comprenne ;)
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 1.
Et en plus tu plussoies !
Ce n'est pas avec des commentaires comme les tiens que l'on fait avancer les choses.
Au contraire, moi, que tu traites de geek (ce qui me fait plaisir) , à travers quelques piques bien placées, j'ai décelé que le problème qu'il a n'a rien à voir avec X, mais tout à voir avec son WM : Enlightenment. Même avec Sawfish il aurait eu des problèmes.
Si je n'ai pas de problèmes, c'est que j'utilise Metacity (le défaut avec Gnome2), qui, lui, est programmé comme il faut à ce niveau là (pour la réactivité).
Et le sentiment que j'ai pendant l'utilisation, je le connais bien, car je suis moi-même utilisateur.
Ceci dit, j'ai testé le redimensionnement sous une Knoppix 3.3 (en ce moement même), avec KDE, avec le driver NVidia de XFree, et c'est vrai que Konqueror met un peu de temps (qques 10e de secondes avant de remettre la page à jour, mais il me semble que je l'avais déjà noté. Idem dans KMail. Ceci dit, ça ne gêne en rien la réactivité. Ca reste plus réactif qu'avec l'Explorer sous le Windows NT4 installé sur la même machine, où on voit clairement les saccades des widgets de barre de défilement lors du redimensionnement, et l'Explorer ne réarrange pas la page lorsque je la redimensionne, alors que Konqueror le fait (donc il fait bien plus de boulot en étant plus réactif).
[^] # Re: Après X, voici Y...
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
Je crois que pour éviter ce genre de malentendu il faut simplement donner plus de détails, ou tout simplement des chiffres (c'est universel ça les chiffres).
Moi ce qui m'interesse(rai) dans ton message, c'est :
- savoir quelle étape est plus rapide (le chargement de l'appli, l'ouverture d'un doc, sa sauvegarde, le clignotement du curseur, le défilement de la page lorsque l'on agit sur l'ascenseur, etc..)
- savoir dans quelle mesure (2 fois plus rapide, 3 fois?)
- éventuellement même pourquoi c'est plus ou moins rapide (petite fouille dans les codes).
Pour mozilla je sais pas, mais pour OpenOffice, la dernière fois que j'ai regardé j'ai eu l'impression qu'ils avaient réinventé la roue (au moins sous Linux). Je veux dire par là qu'ils n'utilisent pas de toolkit standard. J'en veux pour exemple les menu : lorsqu'on ouvre un menu dans OpenOffice, celui-ci reste ouvert même si on va utiliser une autre application. De plus, les fenetre style le 'styliste' ne peuvent pas sortir du document.
A mon avis cela à forcément une incidence sur l'éfficacité de leur couche graphique : quand on réinvente la roue, il faut s'attendre à ce que ce ne soit pas aussi bien que des solutions déjà largement exploitées et améliorées (au mieux ça le sera un jour).
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 1.
Pour OpenOffice, il démarre plus vite sous Windows, car le toolkit utilisé est natif sous Windows, pas sous Linux. Idem pour Mozilla (sauf le Gtk2), et idem pour Eclipse.
Pour chacun, tu as remarqué que c'était plus réactif sous Windows.
Et tu vois, mon problème avec ton message, que dis-je, mes problèmes, sont les suivants :
- Tu attends que ça s'améliore sous Linux, en sous-entendant que parce que trois applis sont mal programmées au niveau graphique sous Linux, alors TOUTES les autres sont comme cela. Ce qui est faux, bien entendu, puisque même Galeon qui n'est pas complètement Gnome, va bien plus vite que Mozilla, pour citer un exemple. Mais tu es sous Enlightenment, donc c'est encore pire, tu as sans doute le problème pour pas mal d'applis.
- Tu reconnais que sous Windows c'est plus réactif et tu utilises Enlightenment. Sais-tu quel âge a Enlightenment ? Enlightenment est buggé et lent, c'est bien connu, et vu que son développement s'est arrêté, ça n'est pas près de changer (à quand E2 ?).
Faut pas se plaindre après ...
[^] # Re: Après X, voici Y...
Posté par Sylvain Briole (site web personnel) . Évalué à 1.
Un chouilla plus jeune que FVWM par exemple, qui tourne pas mal ;-).
Enlightenment est buggé et lent, c'est bien connu, et vu que son développement s'est arrêté, ça n'est pas près de changer (à quand E2 ?).
Bah, "officiellement", Rasterman bosse encore dessus, si j'en crois "ses" news : (http://www.rasterman.com/pages/news.html(...))
Janruary 23, 2003
Second I thought I'd update on some of the Enlightenment work that I've been doing lately. No I haven't quit. I'm still working on it - but it's the building blocks I'm concentrating on at the moment. Enlightenment is not dead. It's quite alive. It's being worked on heavily so the 0.17 release can be what people would expect... and much much more.
[^] # Re: Après X, voici Y...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Tu n'as jamais vu un Windows XP ? Avec curseur et menus transparents, des dégradés de partout, ...
[^] # Re: Après X, voici Y...
Posté par Mickael_83 . Évalué à 1.
>Et finalement je pense qu'il faut toujours, comme aujourd'hui, bien différencier le noyau et la couche graphique comme tu le soulignes... C'est évident... Personne ne remet ca en cause
Pas si évident que ça, regarde M$, OS2. Y'a pas moyen de faire tourner leur système sans la GUI... BeOs j'sais pas j'ai pas testé
Ensuite, question perf, ben sérieux j'avoue ne pas avoir à me plaindre. Certes, mon poste de travail est épuré question fonctions tournantes: pas de mysql, pas de apache, pas de postgres, syslog très allégé bref, pas toutes ces fonctions qui grattent un peu les ressources de la bécanes. Et ça marche fort, malgré ma vieille G400... la lecture divX fenétrée et plein écran passe nickel, Xmms en fond tout ça ça reste réactif très très bien, même pendant que je consulte le net. Prend M$, fait tourner IIS, active directory et un serveur streaming et tu vas délirer sur sa prétendue réactivité (ton 1ghz tournera aussi fort qu'un bon celeron 400/66). Donc, à services et charges égales, je suis pas sûr que la concurrence soit effectivement plus réactive (mais ça c'est un avis perso)
Après, la recompilation de X, j'avoue ne pas l'avoir testé encore, mais je m'y pencherai un de ces 4, avec tout les patchs adéquats... Si t'as des astuces là dessus je suis preneur ;-)
[^] # Re: Après X, voici Y...
Posté par wismerhill . Évalué à 1.
Essaie Linux 2.6, il parrait que l'ordonanceur a subi beaucoup d'améliorations du point de vue de l'interractivité et que l'interface graphique, notament, est beaucoup plus réactive (plus besoin de mettre en nice -10).
[^] # Re: Après X, voici Y...
Posté par ookaze . Évalué à 1.
Euh ... c'est ce qui est réalisé avec le noyau 2.6, sans tomber dans le piège que tu décris, car le but du noyau Linux reste d'être le plus efficace possible pour un maximum d'architectures possible.
Et je recompile mon XFree, ce qui doit prendre environ 45 minutes à ma machine (bi XP 2200), en comptant les render, xrender, xft, freetype, fontconfig et le driver NVidia (toujours bien buggé), et mon bi-pro n'aide pas, car je ne peux pas faire de compil parallèle. Je le fais à chaque fois que je vois un bug qui pourrait m'affecter qui est corrigé. Il n'y a absolument pas besoin de recompiler toutes ses applis (encore heureux) !
Et il me faut bien ça, parce que j'ai 3 Window Manager différents qui tournent sur cette machine (et bientôt 4, comme la famille s'agrandit), avec chacun 4 bureaux virtuels, tous pleins d'applis.
Je ne sais pas si le bi-pro aide dans ce cas pour la latence, mais le seul problème de réactivité que j'ai, c'est si je clique très vite dans Nautilus (sachant que j'ai le thème Nuvola, qui est du SVG).
[^] # Re: Après X, voici Y...
Posté par Mickael_83 . Évalué à 1.
Par contre, t'as regardé si y'a pas des compilateurs SMP ? il m'a semblé en apercevoir sur google quelque chose comme ça, mais je saurais pas te redonner les infos. Parce que pas pouvoir utiliser son SMP pour compiler, franchement, c'est vraiment très c**, et je trouverais ça surprenant que la communauté linux n'y ai pas pensé...
Je disais de recompiler les applics si tu veux aller dans l'extrème : c'est sûr que c'est plus secondaire, mais si tu veux vraiment "tuner" ça un max, ben compiler X en 686 et +, et garder les applics en i386, ça sert pas à grand chose non plus... Mais bon ça deviendrait vite ingérable...:-)
[^] # Re: Après X, voici Y...
Posté par Caeies . Évalué à 1.
Make ne ce charge pas de ça normalement (make -j N -d 10 par ex (si mes souvenirs sont bons))
A moins que X ne se sert par de Make ...
Caeies
mes 2 c
[^] # Re: Après X, voici Y...
Posté par Caeies . Évalué à 1.
[^] # Recompilation
Posté par daggett . Évalué à 1.
# Re: Après X, voici Y...
Posté par Arnaud . Évalué à 2.
[^] # Re: Après X, voici Y...
Posté par Guillaume G. . Évalué à 1.
[^] # Re: Après X, voici Y...
Posté par Yann KLIS (site web personnel) . Évalué à 1.
http://www.stud.uni-karlsruhe.de/~unk6/transluxent/(...)
[^] # Re: Après X, voici Y...
Posté par Arnaud . Évalué à 1.
[^] # Re: Après X, voici Y...
Posté par Keos . Évalué à 1.
Je serait assez interressé par ton projet....si tu pouvais me tenir au courant au cas où tu te lance, j'aurais sans doute quelques suggestion a te faire et des document/travaux perso qui pouront t'aider.
# Amélioration pour X
Posté par Anthony Jaguenaud . Évalué à 2.
Je pense qu'il faudrait refaire une partie de X, car on a quelques années d'utilisations, et plein d'amélioration a faire...
Il faut garder la couche réseau, car elle m'est très utile. Par contre, ne pourrait-on pas intégrer la notion de 3D en plus ? Comme ça, on pourrait faire de la 3D accéléreré sous X, mais pas seulement en local.
[^] # Re: Amélioration pour X
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
[^] # Re: Amélioration pour X
Posté par Arnaud . Évalué à 2.
[^] # Re: Amélioration pour X
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
[^] # Re: Amélioration pour X
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: Amélioration pour X
Posté par Anthony Jaguenaud . Évalué à 1.
Mais, si tu parles de openGL, pour moi :
3D opengl ---> 2D ----> Primitive X ---> Réseau ----> serveur X
En local, on zappe les primitive X ainsi que le réseau pour faire de la 3D accelleré.
Moi, ce que je proposais :
3D ---> primitive X 3D ---> Réseau ( si nécéssaire ) ---> Serveur X 3D qui peut afficher les polygones de manière accéléré. On perdrais un peu de fps à cause du réseau, mais un logiciel comme Blender ou autre pourait etre tout à fait fluide à distance.
[^] # Re: Amélioration pour X
Posté par Arnaud . Évalué à 1.
[^] # Re: Amélioration pour X
Posté par Keos . Évalué à 1.
[^] # Re: Amélioration pour X
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
Moi, ce que je proposais :
3D ---> primitive X 3D ---> Réseau ( si nécéssaire ) ---> Serveur X 3D
Ben oui j'avais bien compris, et, oui, ça existe déja : extension GLX, qui vient de Sillicon.
http://www.opengl.org/developers/documentation/Specs/GLXprotocol.ps(...)
# Re: Après X, voici Y...
Posté par zebul666 . Évalué à 1.
Moi, j'y suis pas arrivé. Comme dit sur le site, il y a des pb.
Alors ?!!??!
[^] # Re: Après X, voici Y...
Posté par Jux (site web personnel) . Évalué à 1.
Ca me donne ca quand je le lance dans KDE (j'arrive pas à le lancer sans XFree qui tourne :-D)
http://mypage.bluewin.ch/julien.r/Y.png(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.