Uniquement pour les 3rd party, aucune application du systeme ne l'utilise et vu la difference de performance, ce n'est pas pret d'arriver. Mais bon, c'est le buzzword du moment et comme de toute facon, tout le monde doit faire par defaut du HTML5, ils annoncent. Ca fait toujours plaisir au marketing.
Le probleme, c'est qu'a partir du moment ou tu veux faire un toolkit graphique. Tu as besoin d'une gestion des event. Tu as besoin d'asynchrone. Tu as besoin de thread. En gros, tu as besoin d'une main loop ! Tu as besoin de discuter avec des process separe, alors tu rajoutes une petite couche reseau pour te connecter au divers demon dont ton framework a besoin pour founir des services plus sur et plus efficacement. Et voila, tu finis forcement avec un framework parce que c'est juste le seul moyen d'implementer un toolkit graphique optimal. Et tant qu'a etre optimal, autant l'etre aussi pour les plus petites applications…
Surement le fait d'avoir 15 milles layer d'abstraction et de code dependant de la version du navigateur sans oublier de prendre en compte l'alignement des planetes. Il faut beaucoup d'imagination pour imaginer une techno plus propre, plus stable et plus perenne dans le temps… ou pas !
Et les operateurs qui croient toujours dans les standards en commite…
Quand a mozilla, ils n'ont pas trop le choix, ils n'ont aucune existence dans le mobile et si ca continu, ils seront irrelevant. C'est juste une question de survie.
La, tu vas trop vite dans le troll. Mais j'ai un contre !
L'erreur fondamental de HTML5, c'est que chacun y vas de son implementation et de sa version. Ca cree une fragmentation titanesque de la plateforme. Plus le temps passe et plus le cout de cette complexite se faira sentir. C'est pas comme si on n'avait pas deja eu le probleme dans le passe. Pour les vieux, les navigateurs WAP avec leur adaptateur de contenu ou le Java MIDP avait eu ce probleme.
Hors aujourd'hui, on voit bien la reussite du modele GNU/Linux, avec une implementation unique, il suffit de cross compiler pour une architecture et tu as le resultat identique partout. De plus le natif offre des avantages de performances non negligeable, sauf a vouloir vivre absolument deux ans dans le passe, parce que c'etait mieux avant.
Donc la logique veut qu'a terme un noyau graphique unique et portable emerge. Qt est bien parti pour dans le domaine. Il y aura forcement quelques solutions concurrentes qui seront a Qt, ce que les BSD sont a GNU/Linux. Mais au final, le natif reprendra sa place apres les incartades de l'HTML5.
Chouette, c'est vendredi et vendredi, c'est troll !
Bon, troller sur le dos d'un cadavre qui n'a meme plus la force de se moderniser, c'est pas tres sympa. Mais on est vendredi, et c'est permi. GTK n'evolue plus. Ils n'ont pas compris l'interet du scenegraph, sont de plus en plus lie a la plateforme GNOME pour etre utilisable et il se retrouve a juste ajouter des nouveaux widgets alors que c'est toute l'infrastructure qu'il faudrait revoir.
A l'oppose Qt depuis la separation de Nokia se porte nettement mieux, evolue dans une direction clair (meme si l'abandon du backend software de qtquick dans la 5.0 est a mon avis une erreur) et a un nombre important de developpeur actif sur leur technologie. Ils sont portable et donne de l'importance a la portabilite de leur plateforme. Il n'y a pas de concurrence possible entre Qt et GTK.
La seule chose qui est domage avec Qt, c'est que KDE utilise vraiment trop de resource et ca donne une mauvaise image de leur techno… Et voila, un petit troll discret pour etre sur que l'on ne va pas en rester la.
Je dis juste que si le window manager s'en occupe, toute tes applications peuvent avoir la meme fonctionnalite que Guake. Il n'est alors plus necessaire d'avoir une application dedie et specialement developpe pour ca. N'importe quel terminal avec le flags "console quake" se comportant alors comme Guake.
Donc je trouve la fonctionnalite de Guake limitante et ne repondant pas au besoin de tous les utilisateurs. Tu es donc un nazi de l'interface pour promouvoir cette application :-D Allez, trollons !
Pour ca que quand j'avais a faire du recrutement au pres de SSII, j'ajoutais des techniques qui n'existaient pas en melangeant des noms de technos existantes. Tres pratique, un bon commercial te rappelle rapidement pour te demander de quoi tu parles parce que la il ne voit pas et tu lui dis que c'est juste une typo. Le mauvais commercial t'envoit des CV avec la techno dessus… Et ca, c'est veridique :-D
Maintenant là ou est l'"anarque" c'est que ce n'est pas du tout sur les postes ingé/dev de haut niveau qu'ils ont ce problème. Alors leur com pourrait faire croire que c'est ca qu'ils forment. Non ils ont des besoins précis sur des postes ou des technos.
Toi, tu n'as jamais essaye de faire un recrutement d'un bon developpeur ! C'est juste une matiere rare, meme quand tu peux offrir un bon salaire en face. Et c'est sous contrainte planetaire. Trouver quelqu'un qui sait bien coder et mettra en code les idees fumeuses de sa hierarchie, ca c'est difficile. Tres difficile !
Le probleme, c'est que les gens pensent que le boulot d'un developpeur est celui d'un techos qui va recevoir les ordres d'un architecte et d'un chef de projet pour pondre un truc qu'il n'arriverait pas a definir par lui meme. Or dans la pratique celui qui code, c'est celui qui cree, c'est celui qui rencontre les contraintes reelles et doit resoudre les problemes. Tant qu'on voit le developpeur comme un executant, les chances de succes d'un projet seront proche de zero. Si le developpeur fait parti du processus creatif, alors les choses changent. Mais il devient alors necessaire de l'inclure des le debut du projet, ce qui implique qu'il est difficile de l'outsourcer a l'autre bout du monde…
Et j'ai vu un paquet de gens avec de bonnes idees essayer de monter des startup en France qui juste n'arrivait pas a mettre la main sur des developpeurs pour les aider. En avoir plus, c'est le seul moyen d'avoir potentiellement plus de nouveau concept cree par l'industrie en France.
1.5 milliards de PC en usage aujourd'hui. 1 milliard de terminaux Android vendu cette annee. Probablement 500 millions de terminaux iOS vendu cette annee. Donc logiquement autant de terminaux mobile vendu que de PC en utilisation a la fin de l'annee. Google te donnera facilement des sources pareil pour Facebook.
Peut etre dans les pays tres developpe, mais dans le reste du monde, le nombre de personne qui peuvent se payer un PC est faible. Il y a une raison pour que Facebook est autant d'acces mobile. D'ailleur a partir de 2014, ils auront plus d'utilisateur mobile que d'utilisateur desktop. Des marches, comme l'Afrique ou la Chine voit un equipement premier en SmartPhone qui remplace un achat de Desktop (C'est aussi probablement le cas pour d'autres pays, mais je ne les connais pas assez pour me prononcer).
Faut arreter de croire que le monde autour de soi correspond a la majorite du monde ;-) Meme au niveau juste Europeen, je suis pres a parier que la situation est la meme dans tous les pays de l'Est. Sans compter qu'avec la crise, les populations vont avoir tendance a se tourner vers la solution qui leur permet d'eviter d'acheter 5 gadgets differents (Un smart phone, c'est une montre, un pc, un telephone, un appareil photo et un ebook au minimum). Les gens qui ont les moyens de se payer ces 5 gadgets individuellements sont de loin les moins nombreux de la planete !
La majorite des developpeurs Android que je connais utilise une Ubuntu dans une VM sur Windows. C'est une partie du calcul qui devient complique, ou alors on part du principe que la somme de tous les OS desktop installe est superieur au nombre de machine et dans ce cas, je ne pense pas que leurs chiffres soit si fume que ca.
Alors le marche des PC installe est de 1.5 milliards d'unites. Ubuntu annonce 30millions d'utilisateurs. Si on fait le calcul, cela veut dire que Ubuntu represente tous les Linux installe, 30*100/1500 = 2%. Je pense donc que le chiffre est probablement plus eleve.
Je suppose que tu veux dire Weston(ou autre compositeur) là.
Par exemple. Je ne cite pas le compositeur, car je trouve cela plus confu au final. Perso, ce sera E18 que j'utiliserais en tant que compositeur utilisateur. Et probablement un compositeur systeme base sur les EFL aussi.
Simple et léger, je veux bien, sécurisé hum, le compositeur normal/de session doit aussi être sécurisé..
Oui, mais tu as des contraintes plus "relaxe" sur celui la. Celui du systeme doit pouvoir reprendre la main si un compositeur utilisateur a fait pouf. Tournant en root, il doit aussi resister aux attaques depuis un utilisateur normal. Un compositeur utilisateur, tourne avec l'identite utilisateur et donc forcement a part se faire mal a soi meme, il n'y a pas d'escalade de privilege. C'etait dans ce sens que je definissais un niveau de securite supplementaire.
comment éviter de perdre en performance
C'est plus une problematique de latence que de performance. Tu n'arriveras jamais meme dans l'embarque a saturer tes inputs face a ton CPU. Par contre, le fait qu'ils doivent passer par 3 process (aller/retour) peut poser un probleme dans les jeux au niveau de la latence. Quand on voit ce que fait X de ce cote la (utilisation de signaux et rendu temps reel de la souris) pour eviter le moindre lag dans l'affichage de celle-ci, la question se pose. Mais a part en ayant un resultat concret et en en voyant l'impact, il est difficile de dire si oui ou non, ca sera genant. C'est quelque chose qui devrait etre a tester par des etres humains, car il n'est pas simple de savoir comment l'etre humain va ressentir la chose.
Oui, avoir une suite de tests, c'est bien. Mais bon, tout le monde c'est quelle ne fait que empecher des problemes qui sont deja arrive d'arriver encore. Elle permet d'eviter les regressions pas vraiment d'avoir une idee de comment les choses vont se passer dans la vrai vie.
Un compositeur systeme est ce qui permettra a terme d'avoir un Wayland qui tourne en tant qu'utilisateur. Un peu comme X qui tournerait sans avoir besoin des droits root. Le compositeur systeme est cense demarrer tres tot dans le processus de boot pour s'occuper d'afficher le splash screen graphique de progress du boot puis le login manager et aussi de gerer le switch vers les consoles virtuels. Dans un systeme wayland comme envisage, il n'y a plus de console kernel en frame buffer, il n'y a plus de multiple switch de resolution et le Wayland qui fait tous les effets graphiques tournent en tant qu'utilisateur. Celui du systeme doit rester simple, lege et securise. Cette une piece centrale pour l'adoption de Wayland sur les distributions Linux desktop.
Le plus complique, c'est les inputs et la consomation batterie. Reussir a faire un compositeur qui en general ne fait que switcher des buffers sans utiliser le GPU, ce n'est pas trivial. Faire un compositeur qui gere toutes les inputs de la planete, vive l'asie, c'est juste un truc que la majorite des occidentaux ne peut juste pas comprendre. Le dernier truc que tu as oublie, c'est la securite, ca ca demande des experts et beaucoup de peer review… La, maintenant, je pense qu'ils vont avoir beaucoup beaucoup beaucoup de mal a faire un truc valable.
Cette demo est representative du code. Un mix de GL et usleep. Afficher quelque chose a l'ecran n'est pas la partie la plus difficile dans la tache de faire un compositeur…
Disons qu'on peut techniquement contourner le probleme (de maniere non optimal) pendant un temps, histoire de forcer la main a NVidia, en faisant passer des buffers XPixmap en tant que buffer Wayland et en utilisant un compositeur X qui implemente uniquement le protocol Wayland en prenant la main completement sur X. Le compositeur s'occupe du rendu, mais il intercepte aussi tous les inputs et il n'autorise l'affichage que via le protocol Wayland.
La plus part des desktops Linux pensent avoir une phase ou ils implementeront Wayland dans leur compositeur X de toute facon. Donc la problematique est finalement de decider de desactiver voir d'empecher l'utilisation de X en direct par les applications et de les forcer a utiliser Wayland ou XWayland.
SurfaceFlinger ne joue pas encore dans la meme categorie. Tu ne peux pas encore gerer un desktop avec. De plus de ma comprehension de ce qu'il est capable d'accelerer, Wayland permet de faire des swap de buffer la ou SurfaceFlinger est force de faire des copies de buffer. Ce qui veut dire que a terme Wayland sera plus performant que SurfaceFlinger.
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 4.
Uniquement pour les 3rd party, aucune application du systeme ne l'utilise et vu la difference de performance, ce n'est pas pret d'arriver. Mais bon, c'est le buzzword du moment et comme de toute facon, tout le monde doit faire par defaut du HTML5, ils annoncent. Ca fait toujours plaisir au marketing.
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 4.
Windows est plus utilise que Linux sur le desktop. Argumentaire de masse toujours imparable.
Et les efls sont certainement plus portable que wxwidgets, a partir du moment ou tu as un framebuffer et un debut de libc, ca passe.
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 4.
Le probleme, c'est qu'a partir du moment ou tu veux faire un toolkit graphique. Tu as besoin d'une gestion des event. Tu as besoin d'asynchrone. Tu as besoin de thread. En gros, tu as besoin d'une main loop ! Tu as besoin de discuter avec des process separe, alors tu rajoutes une petite couche reseau pour te connecter au divers demon dont ton framework a besoin pour founir des services plus sur et plus efficacement. Et voila, tu finis forcement avec un framework parce que c'est juste le seul moyen d'implementer un toolkit graphique optimal. Et tant qu'a etre optimal, autant l'etre aussi pour les plus petites applications…
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 10.
Surement le fait d'avoir 15 milles layer d'abstraction et de code dependant de la version du navigateur sans oublier de prendre en compte l'alignement des planetes. Il faut beaucoup d'imagination pour imaginer une techno plus propre, plus stable et plus perenne dans le temps… ou pas !
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 4.
Et les operateurs qui croient toujours dans les standards en commite…
Quand a mozilla, ils n'ont pas trop le choix, ils n'ont aucune existence dans le mobile et si ca continu, ils seront irrelevant. C'est juste une question de survie.
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 2.
Oui, je me disais que pour ce troll, ce n'etait pas necessaire, mais bon, vendredi n'est pas encore fini ;-)
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 9.
La, tu vas trop vite dans le troll. Mais j'ai un contre !
L'erreur fondamental de HTML5, c'est que chacun y vas de son implementation et de sa version. Ca cree une fragmentation titanesque de la plateforme. Plus le temps passe et plus le cout de cette complexite se faira sentir. C'est pas comme si on n'avait pas deja eu le probleme dans le passe. Pour les vieux, les navigateurs WAP avec leur adaptateur de contenu ou le Java MIDP avait eu ce probleme.
Hors aujourd'hui, on voit bien la reussite du modele GNU/Linux, avec une implementation unique, il suffit de cross compiler pour une architecture et tu as le resultat identique partout. De plus le natif offre des avantages de performances non negligeable, sauf a vouloir vivre absolument deux ans dans le passe, parce que c'etait mieux avant.
Donc la logique veut qu'a terme un noyau graphique unique et portable emerge. Qt est bien parti pour dans le domaine. Il y aura forcement quelques solutions concurrentes qui seront a Qt, ce que les BSD sont a GNU/Linux. Mais au final, le natif reprendra sa place apres les incartades de l'HTML5.
# Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 10.
Chouette, c'est vendredi et vendredi, c'est troll !
Bon, troller sur le dos d'un cadavre qui n'a meme plus la force de se moderniser, c'est pas tres sympa. Mais on est vendredi, et c'est permi. GTK n'evolue plus. Ils n'ont pas compris l'interet du scenegraph, sont de plus en plus lie a la plateforme GNOME pour etre utilisable et il se retrouve a juste ajouter des nouveaux widgets alors que c'est toute l'infrastructure qu'il faudrait revoir.
A l'oppose Qt depuis la separation de Nokia se porte nettement mieux, evolue dans une direction clair (meme si l'abandon du backend software de qtquick dans la 5.0 est a mon avis une erreur) et a un nombre important de developpeur actif sur leur technologie. Ils sont portable et donne de l'importance a la portabilite de leur plateforme. Il n'y a pas de concurrence possible entre Qt et GTK.
La seule chose qui est domage avec Qt, c'est que KDE utilise vraiment trop de resource et ca donne une mauvaise image de leur techno… Et voila, un petit troll discret pour etre sur que l'on ne va pas en rester la.
# Perl
Posté par cedric . En réponse au journal To comment or not to comment. That is the question.. Évalué à 5.
Meme en commentant du Perl, ca t'aidera pas a le relire ! Et puis de toute facon, ce qui est dur a ecrire doit etre dur a lire. Non, mais !
[^] # Re: lapin compris
Posté par cedric . En réponse à la dépêche Guake perd son dernier développeur - appel à un repreneur. Évalué à 3.
Je suis surpris qu'il n'y ait pas moyen avec KDE vu la tripote d'option. Sinon c'est possible dans Enlightenment avec le module QuickAccess.
[^] # Re: Dommage.
Posté par cedric . En réponse à la dépêche Guake perd son dernier développeur - appel à un repreneur. Évalué à 7.
Je dis juste que si le window manager s'en occupe, toute tes applications peuvent avoir la meme fonctionnalite que Guake. Il n'est alors plus necessaire d'avoir une application dedie et specialement developpe pour ca. N'importe quel terminal avec le flags "console quake" se comportant alors comme Guake.
Donc je trouve la fonctionnalite de Guake limitante et ne repondant pas au besoin de tous les utilisateurs. Tu es donc un nazi de l'interface pour promouvoir cette application :-D Allez, trollons !
[^] # Re: Dommage.
Posté par cedric . En réponse à la dépêche Guake perd son dernier développeur - appel à un repreneur. Évalué à 5.
Sans compter que c'est globalement le boulot du window manager de faire ca…
[^] # Re: École pour génie ???
Posté par cedric . En réponse au journal 42 : une nouvelle école informatique. Évalué à 10.
Pour ca que quand j'avais a faire du recrutement au pres de SSII, j'ajoutais des techniques qui n'existaient pas en melangeant des noms de technos existantes. Tres pratique, un bon commercial te rappelle rapidement pour te demander de quoi tu parles parce que la il ne voit pas et tu lui dis que c'est juste une typo. Le mauvais commercial t'envoit des CV avec la techno dessus… Et ca, c'est veridique :-D
[^] # Re: Sur le papier
Posté par cedric . En réponse au journal 42 : une nouvelle école informatique. Évalué à 9.
Toi, tu n'as jamais essaye de faire un recrutement d'un bon developpeur ! C'est juste une matiere rare, meme quand tu peux offrir un bon salaire en face. Et c'est sous contrainte planetaire. Trouver quelqu'un qui sait bien coder et mettra en code les idees fumeuses de sa hierarchie, ca c'est difficile. Tres difficile !
Le probleme, c'est que les gens pensent que le boulot d'un developpeur est celui d'un techos qui va recevoir les ordres d'un architecte et d'un chef de projet pour pondre un truc qu'il n'arriverait pas a definir par lui meme. Or dans la pratique celui qui code, c'est celui qui cree, c'est celui qui rencontre les contraintes reelles et doit resoudre les problemes. Tant qu'on voit le developpeur comme un executant, les chances de succes d'un projet seront proche de zero. Si le developpeur fait parti du processus creatif, alors les choses changent. Mais il devient alors necessaire de l'inclure des le debut du projet, ce qui implique qu'il est difficile de l'outsourcer a l'autre bout du monde…
Et j'ai vu un paquet de gens avec de bonnes idees essayer de monter des startup en France qui juste n'arrivait pas a mettre la main sur des developpeurs pour les aider. En avoir plus, c'est le seul moyen d'avoir potentiellement plus de nouveau concept cree par l'industrie en France.
# Chrome aussi n'est pas neutre
Posté par cedric . En réponse au journal De la neutralité du net .... Évalué à -5.
C'est marrant, mais quand google le fait, les gens se plaignent pas…
https://developers.google.com/chrome/mobile/docs/data-compression
[^] # Re: Une alternative ? Tant mieux
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à -1.
C'est bien tu arrives a te renseigner par toi meme…
[^] # Re: Une alternative ? Tant mieux
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 0.
1.5 milliards de PC en usage aujourd'hui. 1 milliard de terminaux Android vendu cette annee. Probablement 500 millions de terminaux iOS vendu cette annee. Donc logiquement autant de terminaux mobile vendu que de PC en utilisation a la fin de l'annee. Google te donnera facilement des sources pareil pour Facebook.
[^] # Re: Une alternative ? Tant mieux
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 2.
Peut etre dans les pays tres developpe, mais dans le reste du monde, le nombre de personne qui peuvent se payer un PC est faible. Il y a une raison pour que Facebook est autant d'acces mobile. D'ailleur a partir de 2014, ils auront plus d'utilisateur mobile que d'utilisateur desktop. Des marches, comme l'Afrique ou la Chine voit un equipement premier en SmartPhone qui remplace un achat de Desktop (C'est aussi probablement le cas pour d'autres pays, mais je ne les connais pas assez pour me prononcer).
Faut arreter de croire que le monde autour de soi correspond a la majorite du monde ;-) Meme au niveau juste Europeen, je suis pres a parier que la situation est la meme dans tous les pays de l'Est. Sans compter qu'avec la crise, les populations vont avoir tendance a se tourner vers la solution qui leur permet d'eviter d'acheter 5 gadgets differents (Un smart phone, c'est une montre, un pc, un telephone, un appareil photo et un ebook au minimum). Les gens qui ont les moyens de se payer ces 5 gadgets individuellements sont de loin les moins nombreux de la planete !
[^] # Re: Canonical est-elle encore une entreprise souhaitant développer le monde open source ?
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 5.
La majorite des developpeurs Android que je connais utilise une Ubuntu dans une VM sur Windows. C'est une partie du calcul qui devient complique, ou alors on part du principe que la somme de tous les OS desktop installe est superieur au nombre de machine et dans ce cas, je ne pense pas que leurs chiffres soit si fume que ca.
[^] # Re: Canonical est-elle encore une entreprise souhaitant développer le monde open source ?
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 4.
Alors le marche des PC installe est de 1.5 milliards d'unites. Ubuntu annonce 30millions d'utilisateurs. Si on fait le calcul, cela veut dire que Ubuntu represente tous les Linux installe, 30*100/1500 = 2%. Je pense donc que le chiffre est probablement plus eleve.
[^] # Re: Pourquoi pas ? Mais...
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 3.
Par exemple. Je ne cite pas le compositeur, car je trouve cela plus confu au final. Perso, ce sera E18 que j'utiliserais en tant que compositeur utilisateur. Et probablement un compositeur systeme base sur les EFL aussi.
Oui, mais tu as des contraintes plus "relaxe" sur celui la. Celui du systeme doit pouvoir reprendre la main si un compositeur utilisateur a fait pouf. Tournant en root, il doit aussi resister aux attaques depuis un utilisateur normal. Un compositeur utilisateur, tourne avec l'identite utilisateur et donc forcement a part se faire mal a soi meme, il n'y a pas d'escalade de privilege. C'etait dans ce sens que je definissais un niveau de securite supplementaire.
C'est plus une problematique de latence que de performance. Tu n'arriveras jamais meme dans l'embarque a saturer tes inputs face a ton CPU. Par contre, le fait qu'ils doivent passer par 3 process (aller/retour) peut poser un probleme dans les jeux au niveau de la latence. Quand on voit ce que fait X de ce cote la (utilisation de signaux et rendu temps reel de la souris) pour eviter le moindre lag dans l'affichage de celle-ci, la question se pose. Mais a part en ayant un resultat concret et en en voyant l'impact, il est difficile de dire si oui ou non, ca sera genant. C'est quelque chose qui devrait etre a tester par des etres humains, car il n'est pas simple de savoir comment l'etre humain va ressentir la chose.
Oui, avoir une suite de tests, c'est bien. Mais bon, tout le monde c'est quelle ne fait que empecher des problemes qui sont deja arrive d'arriver encore. Elle permet d'eviter les regressions pas vraiment d'avoir une idee de comment les choses vont se passer dans la vrai vie.
[^] # Re: Pourquoi pas ? Mais...
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 7.
Un compositeur systeme est ce qui permettra a terme d'avoir un Wayland qui tourne en tant qu'utilisateur. Un peu comme X qui tournerait sans avoir besoin des droits root. Le compositeur systeme est cense demarrer tres tot dans le processus de boot pour s'occuper d'afficher le splash screen graphique de progress du boot puis le login manager et aussi de gerer le switch vers les consoles virtuels. Dans un systeme wayland comme envisage, il n'y a plus de console kernel en frame buffer, il n'y a plus de multiple switch de resolution et le Wayland qui fait tous les effets graphiques tournent en tant qu'utilisateur. Celui du systeme doit rester simple, lege et securise. Cette une piece centrale pour l'adoption de Wayland sur les distributions Linux desktop.
Le plus complique, c'est les inputs et la consomation batterie. Reussir a faire un compositeur qui en general ne fait que switcher des buffers sans utiliser le GPU, ce n'est pas trivial. Faire un compositeur qui gere toutes les inputs de la planete, vive l'asie, c'est juste un truc que la majorite des occidentaux ne peut juste pas comprendre. Le dernier truc que tu as oublie, c'est la securite, ca ca demande des experts et beaucoup de peer review… La, maintenant, je pense qu'ils vont avoir beaucoup beaucoup beaucoup de mal a faire un truc valable.
[^] # Re: Pourquoi pas ? Mais...
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 3.
Cette demo est representative du code. Un mix de GL et usleep. Afficher quelque chose a l'ecran n'est pas la partie la plus difficile dans la tache de faire un compositeur…
[^] # Re: Une alternative ? Tant mieux
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 2.
Disons qu'on peut techniquement contourner le probleme (de maniere non optimal) pendant un temps, histoire de forcer la main a NVidia, en faisant passer des buffers XPixmap en tant que buffer Wayland et en utilisant un compositeur X qui implemente uniquement le protocol Wayland en prenant la main completement sur X. Le compositeur s'occupe du rendu, mais il intercepte aussi tous les inputs et il n'autorise l'affichage que via le protocol Wayland.
La plus part des desktops Linux pensent avoir une phase ou ils implementeront Wayland dans leur compositeur X de toute facon. Donc la problematique est finalement de decider de desactiver voir d'empecher l'utilisation de X en direct par les applications et de les forcer a utiliser Wayland ou XWayland.
[^] # Re: Une alternative ? Tant mieux
Posté par cedric . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 8.
SurfaceFlinger ne joue pas encore dans la meme categorie. Tu ne peux pas encore gerer un desktop avec. De plus de ma comprehension de ce qu'il est capable d'accelerer, Wayland permet de faire des swap de buffer la ou SurfaceFlinger est force de faire des copies de buffer. Ce qui veut dire que a terme Wayland sera plus performant que SurfaceFlinger.