XMir est la couche de compatibilité X11 donc je ne suis pas sûr de bien comprendre ta question.
Dans Ubuntu 13.10, tu auras matériel --> Mir --> XMir -(X11)-> Unity et applications,
dans le futur Unity et certains applications seront uniquement au dessus de Mir, mais XMir va rester pour les applications X11.
C'est exactement le même principe dans Wayland/XWayland d'ailleurs..
Juste une contribution à la traduction en Français de la documentation de Berlin/Fresco un serveur d'affichage mort il y a longtemps..
De manière amusante sa conception était diamétralement opposée à celle de Wayland, l'idée était d'envoyer des primitives de haut niveau du client vers le serveur.
Si pour toi C-like c'est les accolades OK, mais bon ils ont quand même une grosse différence avec les syntaxe que je qualifie de C-like: leur déclaration des types est dans l'ordre 'Pascalien' donc lisible..
Rust: let monster_size: int = 50;
Scala: val arr = Array[Int]
Non, maintenant si c'est probablement un confort intéressant (jamais utilisé un langage qui a ça donc je ne peux pas parler en connaissance de cause), avoir le compilateur qui vérifie que je couvre bien tout les cas possible me parait beaucoup plus important pour faire évoluer un programme.
Il me semble que la complétude est vérifié aussi en Ada: "In Ada, one advantage of the case statement is that the compiler will check the coverage of the choices, that is, all the values of the subtype of variable X must be present or a default branch when others must specify what to do in the remaining cases."
S'auto heberger pour echapper a l'emprise de Google (comme suggeré par la presentation) pour ensuite synchroniser ses donnees avec Google, c'est un peu ironique, non?
Tu réponds à qui là? Parce que si c'est à moi, je t'invite a relire ce que j'ai marqué, déplacer une fenêtre peut se faire purement coté serveur avec Weston.
Hum, si le gars est capable de miniaturiser un ordinateur suffisamment puissant pour lui donner un réel avantage aux échecs ET en plus de le mettre sous la peau, pas besoin pour lui de jouer aux échecs: il peut être milliardaire demain.
A condition de placer les conditions de base - qui correspondent à ce que l'on veut faire :[coupé]une fenêtre de 300x300 que l'on déplace sur le bureau pendant 10s.
Hein???
Avec Wayland, les applications
1) envoient les buffers entiers contenant leur fenêtre
2) ne connaissent pas leur coordonnées
donc déplacer une fenêtre peut se faire uniquement coté serveur (modulo les histoires de décoration des fenêtres qui sont gérées elle par le client), pourquoi envoyer un écran complet à un affichage distant lorsqu'on déplace une fenêtre?
C'est une implémentation possible ok mais carrément sous-optimal par rapport à ce que le protocole Wayland te permet..
Euh pourquoi?? Tu peux faire un cache des bitmap de glyphes à la XRender.
Ça marche moins bien dans certain cas (traitement de texte qui déforme les caractères suivant leur environnement) mais ça reste très probablement bien supérieur à "je mélange tout" puis j'essaye de compresser le bazar résultant sans être très compliqué..
Le H.264 peut aussi compresser sans perte, mais dans ce cas c'est beaucoup trop lourd.
Et c'est pour ça que d'un point "accès à distance" envoyer les commandes de dessin et non pas le buffer a de l'intérêt..
Ceci dit, un écran d'ordinateur ce n'est pas une caméra donc une compression spécifique (comme celle prototypée par Kristian Høgsberg) pourrait être supérieure après ça ajoute toujours de la latence..
Sinon, étant donné qu'en 2013 la moindre puce ARM à 50 euros intègre un chipset graphique capable d'encoder en H264 en temps réel en 1080px30 fps
Sauf que tu peux déjà acheté un moniteur avec une résolution supérieure..
Et que le 4k va bientôt arriver.
En plus le H264 c'est une compression avec perte pas terrible pour afficher du texte!
qui permettrait au client de déporter le dessin sur le serveur…
Techniquement c'est possible, quoique pas si simple:
1) il faut pouvoir 'synchroniser' l'envoi d'une image normale et d'une image vectorielle superposée, il me semble que dans leur modèle de dessin de "subsurface" les subsurfaces sont disjointes (pas sûr)..
2) il faut trouver le 'bon' jeu d'instructions vectorielles: SVG me parait beaucoup, beaucoup trop gros!
Maintenant comme ça ne rentre pas dans la philosophie du "tout client" je doute que ça ait une chance de rentrer dans le protocole 'standard'.
Un jour, il a dit ça : « Il vaut mieux faire pitié qu'envie ».
J'aime bien ce proverbe retourné, transformé en maxime à la Gandhi, et je comprends ça comme une politique de la liberté, que je rapproche spontanément du monde qui nous occupe dans ces pages && || nos vies : ).
Ah? Moi je prends ça comme un jeu de mot pas terrible: beau sur le papier (car surprenant) mais faux à ~90%.
Sauf que dans le cas du traitement de texte, tu vas vouloir avoir un controle tres fin du rendu,[coupé] Donc je parie que tu ne passes pas aujourd'hui par XRender.
Ça dépend beaucoup du traitement de texte(!), pour pas mal de notepad et consort chaque caractère a un rendu unique où le "glyph cache" fonctionnerait très bien.
sans compter que en terme de performance, c'est du texte que tu veux lire, donc tu n'es pas a vouloir le faire défiler a grande vitesse.
Faux, on passe aussi pas mal de temps à faire défiler rapidement du texte qu'on ne veut pas lire pour arriver à la section qui nous intéresse..
Je parle de la bande passante utilisée et de la latence en accès distant, tu parles des performances en local: je ne vois pas le rapport?
Oui en local utiliser XRender n'a pas de sens, en distant par contre c'est le contraire: se restreindre a envoyer des gros buffer (et avoir soit une grosse utilisation de bande passante, soit une latence dégradée à cause de la compression) est sous-optimal.
j'utilise ssh, un protocol text, fait pour. Pourquoi pousser un protocol graphique ???
Je pense effectivement que c'est ce qui va se passer, les utilisateurs qui avaient l'habitude d'exporter leur terminal passeront par ssh à la place.
Ça ne me pose pas de problème particulier, mais c'est juste un peu pénible d'entendre des Wayland fanboy, dire X c'est tout pourri(vrai), Wayland c'est génial: presque vrai mais uniquement dans 90% des cas, ce n'est pas être contre Wayland que de dire Wayland c'est génial sauf pour exporter du texte en distant ou là (à priori) il vaudra mieux utiliser ssh ou NX (donc X).
Pas d'accord:dire que c'est un combat, c'est rentrer dans le jeu de l'article/troll…
Quand on choisit entre plusieurs solutions on regarde tout les avantages et inconvénients, quand on ne regarde que les inconvénients de X et les avantages de Wayland, bah c'est bien du Phoronix..
Pour GTK le manque de main d'oeuvre est criant, pour Qt il y a un mode XRender (mais ce n'est pas le mode par défaut), un jour où je serai a la retraite (dans 25 ans) ça pourrait m'amuser de comparer les performances en réseau entre ces 2 modes.
Et la marmotte??
Tu pourrais envisager d'avoir un serveur X local au client, qui dessine le résultat dans un buffer puis envoit le delta du buffer "à la Wayland compressé" au serveur d'affichage, mais une fois que tu as créer le buffer qui contient le résultat des instructions de dessins (Wayland), tu ne peux plus revenir en arrière et retrouver les instructions de dessin.
Pour le reste il est vrai que les copies de VRAM --> RAM et RAM --> VRAM additionnelle de Wayland doivent être assez courte, mais n'oublie pas de rajouter l'étape de compression (VRAM --> VRAM) sur le client et de décompression sur le serveur (VRAM --> VRAM) pour avoir un truc avec une bande passante acceptable (spécialement en haute définition).
Ça serait intéressante à tester, je sais qu'il y a une backend RDP pour Wayland mais je n'ai jamais vu de vidéo sur Youtube sur le sujet, c'est curieux et je ne suis donc pas sûr que ça marche vraiment..
Mauvais toolkits, problème d'X??
C'est un peu la même problématique que pour XCB, XLib était pourri OK donc les devs X ont créer XCB (1ère version en 2001, Wayland a été commencé en 2008 et Qt5 va supporter les deux en même temps, chercher l'erreur??) mais les toolkits ne l'adoptent pas, c'est de la faute d'X??
Ma remarque sur les écrans haute définition qui arrivent bientôt (très bientôt même si le 4K prend) s'applique, et là soit on pourra augmenter la compression de buffer à Wayland (dommage pour la latence), soit .. revenir à un système à la X (enfin en supposant que les toolkits fassent bien leur boulot).
[^] # Re: X11 to Mir to X11
Posté par reno . En réponse au journal Des nouvelles de Mir.. Évalué à 4.
XMir est la couche de compatibilité X11 donc je ne suis pas sûr de bien comprendre ta question.
Dans Ubuntu 13.10, tu auras matériel --> Mir --> XMir -(X11)-> Unity et applications,
dans le futur Unity et certains applications seront uniquement au dessus de Mir, mais XMir va rester pour les applications X11.
C'est exactement le même principe dans Wayland/XWayland d'ailleurs..
# Pas grand chose comme contribution
Posté par reno . En réponse au journal Une rétrospective sur mes contributions au libre. Évalué à 4.
Juste une contribution à la traduction en Français de la documentation de Berlin/Fresco un serveur d'affichage mort il y a longtemps..
De manière amusante sa conception était diamétralement opposée à celle de Wayland, l'idée était d'envoyer des primitives de haut niveau du client vers le serveur.
# FrameMaker
Posté par reno . En réponse au sondage Quelle est votre suite bureautique principale ou préférée ?. Évalué à 3.
J'ai utilisé ça (il y a longtemps), ça coûtait un rein mais comme traitement de texte j'ai trouvé que c'était bien au dessus de Word, LO.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par reno . En réponse au journal Ada, langage et ressources. Évalué à 2.
Je pense que c'est parce qu'en mettant les noms des types d'abords tu évite un mot clef: 'int x' suffit par rapport à
'var x: int'.
Après avoir du code 'postfix' f(x) t[i] etc et des déclarations 'préfix', j'ai toujours trouvé ça peu lisible..
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par reno . En réponse au journal Ada, langage et ressources. Évalué à 3.
Si pour toi C-like c'est les accolades OK, mais bon ils ont quand même une grosse différence avec les syntaxe que je qualifie de C-like: leur déclaration des types est dans l'ordre 'Pascalien' donc lisible..
Rust: let monster_size: int = 50;
Scala: val arr = Array[Int]
[^] # Re: langage fonctionnel
Posté par reno . En réponse au journal Ada, langage et ressources. Évalué à 2.
Non, maintenant si c'est probablement un confort intéressant (jamais utilisé un langage qui a ça donc je ne peux pas parler en connaissance de cause), avoir le compilateur qui vérifie que je couvre bien tout les cas possible me parait beaucoup plus important pour faire évoluer un programme.
[^] # Re: Bienvenue dans le merveilleux monde d'Ada !
Posté par reno . En réponse au journal Ada, langage et ressources. Évalué à 2.
Pas vraiment imposée: pour ajouter à Ruby/Python: Scala, Go, Rust, Nimrod (etc) ont pas vraiment avec une syntaxe C-like.
[^] # Re: langage fonctionnel
Posté par reno . En réponse au journal Ada, langage et ressources. Évalué à 3.
Il me semble que la complétude est vérifié aussi en Ada: "In Ada, one advantage of the case statement is that the compiler will check the coverage of the choices, that is, all the values of the subtype of variable X must be present or a default branch when others must specify what to do in the remaining cases."
Donc je pense que tu as répondu un peu vite..
[^] # Re: docs
Posté par reno . En réponse à la dépêche L'auto-hébergement à l'honneur sur Perpignan. Évalué à 0.
C'est pragmatique surtout..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Et si tu lisais la suite tu verrais que ta réponse n'a pas grand sens (en tout cas à ce qu'il me semble).
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Tu réponds à qui là? Parce que si c'est à moi, je t'invite a relire ce que j'ai marqué, déplacer une fenêtre peut se faire purement coté serveur avec Weston.
[^] # Re: Faut le mettre dans une cage !
Posté par reno . En réponse au journal [HS] L'homme bionique est arrivé !. Évalué à 10.
Hum, si le gars est capable de miniaturiser un ordinateur suffisamment puissant pour lui donner un réel avantage aux échecs ET en plus de le mettre sous la peau, pas besoin pour lui de jouer aux échecs: il peut être milliardaire demain.
Un récepteur radio par contre..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 3.
Hein???
Avec Wayland, les applications
1) envoient les buffers entiers contenant leur fenêtre
2) ne connaissent pas leur coordonnées
donc déplacer une fenêtre peut se faire uniquement coté serveur (modulo les histoires de décoration des fenêtres qui sont gérées elle par le client), pourquoi envoyer un écran complet à un affichage distant lorsqu'on déplace une fenêtre?
C'est une implémentation possible ok mais carrément sous-optimal par rapport à ce que le protocole Wayland te permet..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Euh pourquoi?? Tu peux faire un cache des bitmap de glyphes à la XRender.
Ça marche moins bien dans certain cas (traitement de texte qui déforme les caractères suivant leur environnement) mais ça reste très probablement bien supérieur à "je mélange tout" puis j'essaye de compresser le bazar résultant sans être très compliqué..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Et c'est pour ça que d'un point "accès à distance" envoyer les commandes de dessin et non pas le buffer a de l'intérêt..
Ceci dit, un écran d'ordinateur ce n'est pas une caméra donc une compression spécifique (comme celle prototypée par Kristian Høgsberg) pourrait être supérieure après ça ajoute toujours de la latence..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 3.
Sauf que tu peux déjà acheté un moniteur avec une résolution supérieure..
Et que le 4k va bientôt arriver.
En plus le H264 c'est une compression avec perte pas terrible pour afficher du texte!
# Bof
Posté par reno . En réponse au journal Déclaration de dépendance du cyberspace. Évalué à 3.
Ce n'est pas parce que quelqu'un se pignole en se gargarisant de grand mots qu'il faut faire la même chose, même pour démonter ses arguments foireux.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Techniquement c'est possible, quoique pas si simple:
1) il faut pouvoir 'synchroniser' l'envoi d'une image normale et d'une image vectorielle superposée, il me semble que dans leur modèle de dessin de "subsurface" les subsurfaces sont disjointes (pas sûr)..
2) il faut trouver le 'bon' jeu d'instructions vectorielles: SVG me parait beaucoup, beaucoup trop gros!
Maintenant comme ça ne rentre pas dans la philosophie du "tout client" je doute que ça ait une chance de rentrer dans le protocole 'standard'.
# Ah?
Posté par reno . En réponse au journal Maurice Nadeau bronsonisé.. Évalué à 4.
Ah? Moi je prends ça comme un jeu de mot pas terrible: beau sur le papier (car surprenant) mais faux à ~90%.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 1.
Ça dépend beaucoup du traitement de texte(!), pour pas mal de notepad et consort chaque caractère a un rendu unique où le "glyph cache" fonctionnerait très bien.
Faux, on passe aussi pas mal de temps à faire défiler rapidement du texte qu'on ne veut pas lire pour arriver à la section qui nous intéresse..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 1.
Je parle de la bande passante utilisée et de la latence en accès distant, tu parles des performances en local: je ne vois pas le rapport?
Oui en local utiliser XRender n'a pas de sens, en distant par contre c'est le contraire: se restreindre a envoyer des gros buffer (et avoir soit une grosse utilisation de bande passante, soit une latence dégradée à cause de la compression) est sous-optimal.
Je pense effectivement que c'est ce qui va se passer, les utilisateurs qui avaient l'habitude d'exporter leur terminal passeront par ssh à la place.
Ça ne me pose pas de problème particulier, mais c'est juste un peu pénible d'entendre des Wayland fanboy, dire X c'est tout pourri(vrai), Wayland c'est génial: presque vrai mais uniquement dans 90% des cas, ce n'est pas être contre Wayland que de dire Wayland c'est génial sauf pour exporter du texte en distant ou là (à priori) il vaudra mieux utiliser ssh ou NX (donc X).
[^] # Re: Combat ?
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 2.
Pas d'accord:dire que c'est un combat, c'est rentrer dans le jeu de l'article/troll…
Quand on choisit entre plusieurs solutions on regarde tout les avantages et inconvénients, quand on ne regarde que les inconvénients de X et les avantages de Wayland, bah c'est bien du Phoronix..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à -1.
Pour GTK le manque de main d'oeuvre est criant, pour Qt il y a un mode XRender (mais ce n'est pas le mode par défaut), un jour où je serai a la retraite (dans 25 ans) ça pourrait m'amuser de comparer les performances en réseau entre ces 2 modes.
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 0.
Et la marmotte??
Tu pourrais envisager d'avoir un serveur X local au client, qui dessine le résultat dans un buffer puis envoit le delta du buffer "à la Wayland compressé" au serveur d'affichage, mais une fois que tu as créer le buffer qui contient le résultat des instructions de dessins (Wayland), tu ne peux plus revenir en arrière et retrouver les instructions de dessin.
Pour le reste il est vrai que les copies de VRAM --> RAM et RAM --> VRAM additionnelle de Wayland doivent être assez courte, mais n'oublie pas de rajouter l'étape de compression (VRAM --> VRAM) sur le client et de décompression sur le serveur (VRAM --> VRAM) pour avoir un truc avec une bande passante acceptable (spécialement en haute définition).
Ça serait intéressante à tester, je sais qu'il y a une backend RDP pour Wayland mais je n'ai jamais vu de vidéo sur Youtube sur le sujet, c'est curieux et je ne suis donc pas sûr que ça marche vraiment..
[^] # Re: Un article partial: parfait pour un Vendredi.
Posté par reno . En réponse à la dépêche Le combat X contre Wayland : les faits vus par Eric Griffith. Évalué à 0.
Mauvais toolkits, problème d'X??
C'est un peu la même problématique que pour XCB, XLib était pourri OK donc les devs X ont créer XCB (1ère version en 2001, Wayland a été commencé en 2008 et Qt5 va supporter les deux en même temps, chercher l'erreur??) mais les toolkits ne l'adoptent pas, c'est de la faute d'X??
Ma remarque sur les écrans haute définition qui arrivent bientôt (très bientôt même si le 4K prend) s'applique, et là soit on pourra augmenter la compression de buffer à Wayland (dommage pour la latence), soit .. revenir à un système à la X (enfin en supposant que les toolkits fassent bien leur boulot).