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.
![[en]](../images/en.png)
Le document (pdf) (1004 hits)-
La page du projet (2014 hits)
-
L'article sur OSNews (543 hits)
> Lire la dépêche (97 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #275708.
Run by 
Cette page a été générée par Templeet en 0.1207s (dont 0.0112 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re: Après X, voici Y...
Ça commence doucement à me saouler d'entendre dire partout que X est lent à cause de la couche réseau. Ce mythe a la vie dure.
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...
Je plussoie.
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...
[+]
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...).
[^]Re: Après X, voici Y...
Je suis d'accord qu'on tape un peu trop facilement sur X window concernant ça lenteur.
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...
Moi je le fais souvent et je n'ai aucun problème. C'est une question de goût.
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...
"Ça commence doucement à me saouler d'entendre dire partout que X est lent à cause de la couche réseau. Ce mythe a la vie dure."
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...
Si j'ai bien compris le rapport, ce qui pose probléme sur X, c'est le manque de bufferisation, ou j'ai mal compris ?
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...
> Si j'ai bien compris le rapport, ce qui pose probléme sur X, c'est le manque de bufferisation, ou j'ai mal compris ?
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...
Un autre probleme est l'absence de synchro entre le window manager et les applications.
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...
Je trouve ca ridicule (dans ce cas du moins) d'envoyer des événement à une frequence superieur à la fréquence de rafraichissement de l'écran, non ?
[^]Re: Après X, voici Y...
Autant que je sache, X11 ne permet pas de se synchroniser sur la frequence d'ecran. Cela n'aurait pas vraiment de sens quand le DISPLAY est exporte par le reseau. Meme si cela etait possible, cela ne resoudrait pas necessairement le probleme car beaucoups d'ecrans tournent a plus de 100 img/sec.
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...
Je n'ai pas ce comportement à la maison, sauf pour certaines applis sous KDE (Konqueror je crois), et cela fait longtemps (depuis les débuts de Gnome 2.1 je crois, et le début de KDE 3).
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...
Oui, mais le protocol X reste quand même d'assez bas niveau ...
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...
sigh...
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...
> 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.
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...
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
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...
Oui, effectivement, l'utilisation de macros serait là une excellente idée ! et au moins, on continuerait à ne pas imposer un toolkit particulier (ce qui est à la fois un problème -- manque de cohésion -- et un avantage -- grande variété de toolkits et langages possibles)...
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...
Je ne vois pas bien où ça se place par rapport à X. Déjà, il est question d'utiliser l'extension X-Render pour profiter d'une possible accélération matérielle, mais il n'y a pas beaucoup de cartes qui ont l'air de supporter l'extension X-Render au niveau matériel http://xwin.org:9673/xwin/DUDP(...) ...
L'utilisation d'OpenGL, ça pourrait servir à remplacer X-Render ou j'ai rien compris (je pencherais pour le n°2).
« Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
- Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
[^]Re: Après X, voici Y...
En fait un accélérateur matériel sert à effectuer une même opération bien plus rapidement dans la mesure où l'on sait que le périphérique utilisé est spécialement doué pour effectuer cette tâche en particulier. Mais l'opération elle-même n'est pas optimisée, la manière de procéder reste la même.
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...
> et on ne peut PAS imposer aux développeurs d'utiliser une SEULE toolkit
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...
N'empeche quand je vois Quartz par rapport a X11 je pleure !
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...
Je vais faire le rabojoie (j'avais poster un journal la dessus) : Quartz (ou une couche pas loin) implémente chaque fenêtre comme une texture dans la carte graphique --> déplacer une fenêtre revient à deplacer la texture à l'écran ce qui est beaucoup plus rapide que de demander aux apps de redessiner leurs fenêtres.
(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...
Quartz (ou une couche pas loin) implémente chaque fenêtre comme une texture dans la carte graphique --> déplacer une fenêtre revient à deplacer la texture à l'écran ce qui est beaucoup plus rapide que de demander aux apps de redessiner leurs fenêtres.
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...
T'as vu joué ça où que l'interface graphique de MacOsX est lente...franchement j'ai rarement vu une interface aussi rapide/fluide et qui donne autant un sentiment de rapidité...et pourtant mon portable g3 n'est pas une foudre de guerre
[^]Re: Après X, voici Y...
quelle config ? parce que bon, j'ai un ibook 600 avec 256 mo de ram et une bêta OSX 10.3, bon, ça tourne bien, mais de là à dire "rarement vu une interface aussi rapide/fluide et qui donne autant un sentiment de rapidité" .. heu... linux est plus réactif sur la même bécane.
Bon c'est un ibook2 avec Ati Rage 128, donc pas de Quartz Extrem hein.
[^]Re: Après X, voici Y...
C'est bien Quartz qui fait ca, et plus précisément le "compositor", qui est la dernière étape avant l'acces au matériel vidéo.
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...
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.
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...
En tant qu'utilisateur d'XFree à la limite je me fous completement de savoir si oui ou non il est capable de gèrer le canal Alpha. Tu me dis que oui et moi je constate que non. Ne viens pas me parler des terminal pseudo transparent qui quand on les bouges ne le sont plus tant que ca et qui ne font que capturer le background une fois qu'on arrete de les bouger. Si c'est ca que tu appel "un veritable canal alpha", tu ferait bien de toucher un peu a gimp ou photoshop pour comprendre de quoi je parle. Et tu vois les pb de sécurité, a la limite en tant qu'utilisateur je m'en fous aussi, ce que je veux c'est que ca marche, et il n'y a que ca que je juge.
[^]Re: Après X, voici Y...
Tu te fiches de la sécurité ? Tu te fiches du fait qu'une appli puisse te bloquer tout ton serveur X ? Je ne trouve pas ça très intelligent, mais c'est ton problème. Je suis très satisfait du fait que X empêche un flood par une appli quelconque.
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...
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...
Lol je ne me fous pas de "la securité", je me fous completement du fait que ce soit pour un pb de sécurité que la transparence ne fonctionne pas !!! L'utilisateur souhaite que ca marche et que ca soit sécurisé !
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...
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...
Pour ajouter une illustration : si Guillaume Maillard considère X suffisament rapide pour construire B.E.OS, je crois que X est bien assez rapide pour moi.
Lisez donc ça, c'est très intéressant et plein de vrais chiffres concrets :
http://osnews.com/story.php?news_id=1905(...)
[^]Re: Après X, voici Y...
Il n'a jamais choisit le noyau linux ou méme X pour leurs rapidité ( quoi que ce soit en partie faux pour le kernel ), mais principalement pour leurs bon support materiel, il l'explique trés clairement.
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
[^]Re: Après X, voici Y...
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...
MAIS il faut explicitement utiliser l'API de SHM pour ca
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 ...