Pour le deux, le fait que Pekka Paalanen soit un tres important contributeur du projet Wayland/Weston tant a accredite la contribution positive de Collabora sur le sujet. Cela penche pour moi plutot en faveur de l'aide general au projet Wayland.
Ce n'est pas comme si il y avait aujourd'hui beaucoup d'activite qui tente de faire tourner un desktop avec Wayland. Donc valider le protocol, son implementation et son utilisabilite dans ce cas, sur un materiel tres tres limite, me semble faire partie d'une contribution importante au projet Wayland.
Mais bon, apres on peut toujours trouver une raison de se plaindre…
Whaou ! Trois lignes, deux erreurs ! Impressionnant le niveau de desinformation ! Reprenons donc dans l'ordre.
iPhone OS (avant qu'il s'appelle iOS :p) et Android faisait des choses similaires ya 5 ans (iphone 3g avec un armv6, qui etait plus que décent niveau performances graphiques).
iPhone et Android ne font pas de rendu partiel encore aujourd'hui. Rendu fullscreen en permanence plus swap de buffer. Niveau consomation d'energie et efficacite, Weston doit pouvoir facilement leur mettre la grosse pate dans un usage typique de PC. Toute ces fenetres qui ne sont pas full screen, ca va leur poser des soucis quand meme. Sans compter l'utilisation efficace des layers hardware aussi.
Et puis, c'est pas comme si les applications pour telephone avait moins de feature qu'une application GNOME. Meme si GNOME travail a resoudre activement se probleme :-)
Que X11 est pourri, inadapte en 2013 et inutilisable dans le monde mobile?
X11 est tellement pourri qu'avec un driver classique, et bien, tu consommes 10% de ressource en moins que Android… Si ton telephone a une duree de vie de 20h avec Android, ca te fait 22h avec Linux/X11. Je sais pas, mais ma definition de pourri ne match pas, va falloir que tu me donnes la tienne.
Bien entendu le test est fait sur du materiel bien supporte de chaque cote avec une application visuellement identique. Ah, remarque, j'ai oublie de signaler, c'est teste avec Enlightenment et les EFL, je ne sais pas ce que les autres toolkit donnent comme resultat. Mais bon, ca prouve que le probleme, c'est pas X. Et toutes personnes pensant differemment ne connaient juste pas la stack graphique de Linux.
PS: Passe a Wayland est une necessite, mais faut pas croire que ca donnera un plus gros avantage aux logiciels libres, si personne ne pousse une plateforme avec pour le grand public. Ca se saurait quand meme si l'efficacite d'une solution technique etait lie a son utilisation !
Il y a 15 ans, on enfume nos profs en leur faisant une joli demo avec des pixels qui bougent sur une grosse machine pour eviter d'avoir des questions trop techniques sur comment ca marche… Comme quoi ca marche toujours aussi bien comme technique !
Plus serieusement, la difficulte dans un compositeur n'est pas d'afficher quelque chose a l'ecran encore moins sur un laptop moderne comme utilise dans la video. Dans l'ordre les difficultes :
- afficher efficacement en utilisant le moins d'energie possible
- avoir un protocol securise
- gerer les inputs dans tous les contextes efficacement
- avoir un protocol stable et evolutif pour quelques decennies
Si on ajoute a cela que l'on veut suivre des use case generique et non pas se limiter a Unity, tout d'un coup cette demo perd beaucoup d'interet… Elle ne montre finalement qu'un compositeur limiter tournant en frame buffer.
Pour le troll, Canonical se prend pour Google et essaye de creer sa propre stack qu'elle controlera completement. Le developpement est fait tout seul dans son coin sans tenter d'avoir une communaute de developpeur externe. Enfin je te conseille de prendre ton laptop, installer une Ubuntu et faire un petit test avec powertop, puis installe une distrib un peu plus clean avec GNOME, KDE et Enlightenment. Regarde quel setup te faira gagner le plus de batterie…
Je parle de randonnee ici, avec sac a dos, tente or refuge ! Ca donne de tres belle vue, mais il vaut mieux planifier un rien son itineraire quand meme :-)
Il y a rarement un seul chemin pour faire 15km :-) Et la ou je fais de la randonnee, je passe un peu de temps a devoir regarder les cartes pour justement choisir le trace le plus interressant. Un mix de point de vue et d'optimisation de parcour.
Impressionnant comme boulot, openstreetmap est vraiment une plateforme qui a de plus en plus d'interet. Ca fait deux fois que je pars en vacances et que la meilleure cartographie est fournit par Openstreetmap et marche en plus offline ! J'aurais juste deux questions :
Est-ce qu'il serait possible d'en faire une version offline en recuperant juste la base de donnees Postgresql par exemple ? En gros, ton serveur Postgresql consomme combien de ram ? Et quel est la puissance processeur minimal necessaire pour resoudre un itineraire ?
Et tu aurais la meme chose en stock pour la randonnee ? :-)
Il y a forcement toujours une cooperation entre l'application et le serveur. L'explication donnee sur le fait de retirer les buffer a l'application est aussi une mauvaise raison. Si tu retires un buffer a l'application, celle-ci ne doit pas etre entrain de l'utiliser, donc tu as forcement cooperation. Ensuite tu peux toujours bloquer le retour du prochain buffer cote server pour forcer un ralentissement de ton application, mais ca c'est aussi bien possible dans Mir que Wayland. Et dans le port Wayland via libhybris l'allocation est fait cote serveur…
Et pour ce qui est des chiffres de performance, je connais au moins une implementation de Wayland qui est 10% plus performante que SurfaceFlinger (le compositeur de Android) avec des drivers bien pourri. Ubuntu d'un autre cote sur mon PC est un goinfre energetique et ils ne sont pas trop repute de ce cote la. Sur mon Nexus 7, ca le rend juste inutilisable… Mais bon, on va leur laisser le benefice du doute pour l'instant, ca se trouve ils vont faire un truc techniquement bien pour une fois Ubuntu… On sait jamais !
Il y a combien de RPi dans la nature ? Et ca represente quelle part du "desktop" Linux ? Il faut des fois mettre les choses en perspective, on n'est pas forcement representatif. Pour ceux qui en est de Mir, c'est incroyable la confiance aveugle que les gens peuvent avoir dans une solution faite par des gens qui ne connaissent rien a la realisation d'un compositeur graphique, la securite et les methodes d'input. C'est bien, ils apprendront, mais le resultat, a part etre la propriete de Ubuntu, n'aura d'interet pour personne.
En meme temps, ca ne dit pas quelle version du protocol est supporte. Je suis meme incapable de le dire pour les EFL… Et pourquoi cocorico pour les EFL ? On a certe la communaute la plus active en France. Mais on a plus d'utilisateur en Allemagne et les developpeurs sont repartis un peu de toutes les nationalites.
C'est juste pas une raison technique du tout. Wayland ne definit pas ce qu'est un buffer et qui est en charge de l'allocation. Un buffer peut etre un truc genere par KMS/DRM, gralloc, malloc, voir meme un XPixmap. C'est juste du bullshit de leur part et ca a d'ailleur ete demontre par l'equipe de Sailfish qui fait tourner Wayland sur des drivers Android…
Ca c'est encore pas tres evident. Il n'est pas clair pour l'instant de savoir si Mir s'appuiera sur KMS ou sur les driver Android ou les deux. Mais effectivement, ca a ete une rumeur. En meme temps, il leur reste un an avant de sortir un truc…
Je ne sais pas ou tu as vu ca. Je n'ai pas entendu cette info de la part des devs qui sont passe sur les differents forums. Mais bon, mir est developpe dans son coin par ubuntu sans vraiment communiquer avec qui que ce soit…
Euh, juste comme ca, Weston n'est pas destine a etre utilise par madame Michu. C'est un validateur technologique du protocol Wayland. Il s'avere utilisable, mais son but n'est pas de remplacer Kwin, Enlightenment et consort. C'est a ces projets d'implementer le protocol Wayland et de fournir un desktop pour madame Michu. Weston sert a faire avancer les bibliotheques commune et a defricher le travail pour eux, mais ca laisse quand meme pas mal de boulot au dev de ces compositeurs.
Sinon mir semble ne pas avoir les meme objectifs que Wayland. Aussi bien en terme de performance, portabilite que de gestion de systeme d'input, mir ne semble pas du tout viser le cote generaliste de Wayland. Et pour le cout, aucun projet upstream ne va passer du temps dessus, donc il y a peut etre autant de dev sur Wayland que sur mir, mais upstream, il n'y en a pas. Et c'est toute la difference.
D'ailleur pour lancer un beau troll, il n'y a aucune justification technique a l'existence du protocol de mir. Ils auraient tres bien pu implementer leur compositeur Wayland sans plus de souci…
Ah la comprehension des licenses en Asie. Tout un programme ! Si c'est un mtk, peut etre que ce que tu trouveras sur : http://www.wikogeek.com/ pourra t'aider. J'ai pas encore regarde, mais enormement de telephone asiatique utilise cette puce et il n'y a quasiment jamais de difference au niveau hard entre ces telephones.
Le probleme de powertop, c'est qu'il mesure l'activite durant la decharge de la batterie. Si la batterie ne se decharge pas assez vite pour etre mesurer, alors il pense qu'il n'a pas consomme d'energie. En espacant au maximum les points de mesure, cela resoud le probleme… pour l'usage de powertop. Dans le cas d'un benchmark tel que celui-ci, je pense qu'il serait plus pertinent d'avoir une trace de la consomation en temps reel et qu'on puisse lq piloter en simultane de l'execution du benchmark. En gros, je cherche une sonde materiel qui puisse memoriser une trace et se faire piloter via usb.
Desole, mais une interface en ncurse, ce n'est ni moderne ni joli. C'etait moderne dans les annees 70. Depuis, il y a eu Xerox, l'Apple II, XWindow et d'autre truc comme ca. C'est bien de troller, mais quand meme croire qu'il suffit de remplacer les quelques characteres colorise par des nimages pour avoir une interface moderne, c'est juste soit de la mauvaise fois, soit de l'incompetence. Vu qu'on est entrain de troller, je suis plus tenter par la premiere explication ;-)
Oui. Portage vers Wayland, c'est juste ajoute un nouveau backend (creation de fenetre et recuperation des events) et regarder les problemes d'integration (vu qu'une partie de la gestion de fenetre est faite par l'application). Il n'y a pas de changement du modele de rendu, pas d'amelioration interne du toolkit. Et c'est necessaire pour la survie du toolkit sous Linux. Donc c'est de la maintenance. Pour le support des ecrans haute resolution, a part faire des graphismes plus fin, je vois meme pas ce que ca va changer dans le code !
Tu as répondu pour wesnoth. Tu pourrais répondre la même chose pour flare (mais tu ne connais peut-être pas ce jeu) sauf que les problèmes de perf ne sont pas aussi critiques (le jeu est moins lourd, et pas fini, ça doit aider).
Non, je ne connais pas flare du tout.
Par contre, tu as laissé aptitude de côté? Et je vais ajouter ncmpcpp aussi, tiens.
Non, mais serieux, Ncurses quoi ! On parle d'interface graphique quand meme ! Parce que bon, c'est pas juste les degrades et les fioritures graphiques en moins, c'est toute l'ihm qui fait penser aux annees 80, la ! Sur que ca demande pas autant d'effort de pousser quelques characteres colorise face a des millions de pixels. Donc forcement, on n'a pas trop besoin de se poser de question. Et puis le cote asynchrone on s'en tappe un peu, les utilisateurs sont habitue a ce que ca bloque sur ce genre d'interface ! Quelle blague !
Windows est plus utilise que Linux sur le desktop. Argumentaire de masse toujours imparable.
Désolé de considérer que les applications que je fais doivent pouvoir tourner sur la plus grande quantité possible de cibles.
J'aurais du faire une quote, parce que bon, la, ton argumentaire, c'etait: "parce que c'est plus utilise, c'est donc un meilleur choix". Maintenant tu en changes la comprehension…
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.
Je vais même t'aider un peu. D'ailleurs, en tant que personne qui les promeut, sache que tu me déçois énormément de ne pas avoir toi-même cité une partie de ce passage du site officiel:
Enlightenment and EFL support several platforms, though Linux is the primary platform of choice for our developers, some make efforts to make things work on FreeBSD and other BSD's, Solaris, MacOS X, Windows (XP, Vista, 7 etc.), Windows CE and more. Compatibility will vary , but most of core EFL support all Linuxes, BSD's, Solaris and other UNIX-like OS's. Mac support should work mostly thanks to the X11 support in OS X, and Windows support exists for most of the core libraries (XP, Vista, 7, CE).
Mais peut-être est-ce dû aux nombreuses portions de phrase qui donnent une impression de truc pas fini?
Si j'utilise des lib de préférence portable, c'est justement pour ne pas avoir besoin de galérer à vérifier quelle fonctionnalité l'est ou pas, personnellement.
Ca ne change rien a ce que j'ai dis. Les EFL tournent sur plus de materiel que wxWdiget ne pourra jamais le faire. C'est juste un fait. La portabilite des EFL fait que si ta machine n'est pas suffisante pour, alors tu peux oublier tous les autres framework. Apres qu'on ne garantisse pas l'equivalence de fonctionalite, en tant que logiciel libre, c'est un peu normal. C'est le boulot d'une societe de faire la partie QA. En temps que logiciel libre, on fait que ca marche bien pour notre usage et on resoud autant que possible les bugs rapporte par nos utilisateurs. D'ailleur je crois qu'on n'a pas besoin du support X11 pour OS X, elle n'est pas a jour cette page !
Enfin bon… il y a une façon simple de savoir si les gens préfèrent les EFL à wxWidgets ou le contraire, et c'est de voir des applications célèbres les utilisant. Sans même prendre la peine de réfléchir, wxWidgets a FileFilla.
C'est marrant, mais je n'ai jamais utilise la moindre application fait avec wxWidgets. Tu m'aurais dis Qt, GTK, meme XUL, j'aurais dis OK, mais wxWidget, c'est vraiment pas le genre d'application que j'utilise. Et pourtant j'ai cherche dans la liste de leur site, mais nop. D'ailleur quand on voit la liste, c'est vraiment de l'institutionnel, pas vraiment un domaine que je croise souvent.
Tres bien comme exemple Wesnoth. Le fait qu'il ne s'appuie pas sur un toolkit 2D performant fait qu'ils ont du reinventer pas mal de chose et contrairement a un projet dont c'est le but, ils sont loin d'etre aussi performant qu'il pourrait l'etre. Ils ont aussi du mal a pouvoir faire de l'OpenGL/OpenGL ES.
Avec un framework plus complet, ils auraient beneficie d'une boucle de rendu performante. D'un demarrage plus rapide en partageant des ressources avec le reste du systeme. Peut etre aussi une solution plus securise en separant le process qui charge les ressources du process principal.
Mais ils ont decide d'utiliser un toolkit plus simple. En fait, c'est un framework, mais juste plus bas niveau, la SDL. Pour le reseau, je ne pense pas me tromper en disant qu'ils utilisent SDL_Net. Donc ils ont bien utilise un framework. D'ailleur la SDL, n'est pas vraiment un toolkit graphique, vu que les primitives graphiques qu'elle fournit sont tres limite et que les applications doivent redevelopper quasiment toute leur boucle de rendu.
Pour FLTK, je n'ai aucune idee de ces limites, mais c'est aussi gros que les EFL. Donc pour un toolkit qui ne fait que l'IHM, tu "gagnes" pas grand chose..
Par contre, avoir un évènement "rappelle-moi quand il y a des données sur ma socket sans bloquer le GUI en attendant", c'est top et ca se fait sans threads…
Tu fais comment la decompression d'image sans bloquer ta main loop. Tu fais comment l'upload de texture sans bloquer ta main loop. Tu fais comment le rendu d'une frame sans bloquer ta main loop. Donc oui, c'est necessaire d'avoir une bonne boucle d'evenement, mais ce n'est pas suffisant. Aujourd'hui faire un toolkit graphique performant sans utiliser de thread, ca va etre… comment dire… bloquant ! :-)
[^] # Re: Vraiment intéressant ?
Posté par cedric . En réponse au journal Wayland/Weston sur Raspberry Pi dès cette année. Évalué à 9.
Pour le deux, le fait que Pekka Paalanen soit un tres important contributeur du projet Wayland/Weston tant a accredite la contribution positive de Collabora sur le sujet. Cela penche pour moi plutot en faveur de l'aide general au projet Wayland.
Ce n'est pas comme si il y avait aujourd'hui beaucoup d'activite qui tente de faire tourner un desktop avec Wayland. Donc valider le protocol, son implementation et son utilisabilite dans ce cas, sur un materiel tres tres limite, me semble faire partie d'une contribution importante au projet Wayland.
Mais bon, apres on peut toujours trouver une raison de se plaindre…
[^] # Re: Ne pas survendre..
Posté par cedric . En réponse au journal Wayland/Weston sur Raspberry Pi dès cette année. Évalué à 10.
Whaou ! Trois lignes, deux erreurs ! Impressionnant le niveau de desinformation ! Reprenons donc dans l'ordre.
iPhone et Android ne font pas de rendu partiel encore aujourd'hui. Rendu fullscreen en permanence plus swap de buffer. Niveau consomation d'energie et efficacite, Weston doit pouvoir facilement leur mettre la grosse pate dans un usage typique de PC. Toute ces fenetres qui ne sont pas full screen, ca va leur poser des soucis quand meme. Sans compter l'utilisation efficace des layers hardware aussi.
Et puis, c'est pas comme si les applications pour telephone avait moins de feature qu'une application GNOME. Meme si GNOME travail a resoudre activement se probleme :-)
X11 est tellement pourri qu'avec un driver classique, et bien, tu consommes 10% de ressource en moins que Android… Si ton telephone a une duree de vie de 20h avec Android, ca te fait 22h avec Linux/X11. Je sais pas, mais ma definition de pourri ne match pas, va falloir que tu me donnes la tienne.
Bien entendu le test est fait sur du materiel bien supporte de chaque cote avec une application visuellement identique. Ah, remarque, j'ai oublie de signaler, c'est teste avec Enlightenment et les EFL, je ne sais pas ce que les autres toolkit donnent comme resultat. Mais bon, ca prouve que le probleme, c'est pas X. Et toutes personnes pensant differemment ne connaient juste pas la stack graphique de Linux.
PS: Passe a Wayland est une necessite, mais faut pas croire que ca donnera un plus gros avantage aux logiciels libres, si personne ne pousse une plateforme avec pour le grand public. Ca se saurait quand meme si l'efficacite d'une solution technique etait lie a son utilisation !
# C'est zoli !
Posté par cedric . En réponse au journal Mir est peut-être une hérésie mais.... Évalué à 7.
Il y a 15 ans, on enfume nos profs en leur faisant une joli demo avec des pixels qui bougent sur une grosse machine pour eviter d'avoir des questions trop techniques sur comment ca marche… Comme quoi ca marche toujours aussi bien comme technique !
Plus serieusement, la difficulte dans un compositeur n'est pas d'afficher quelque chose a l'ecran encore moins sur un laptop moderne comme utilise dans la video. Dans l'ordre les difficultes :
- afficher efficacement en utilisant le moins d'energie possible
- avoir un protocol securise
- gerer les inputs dans tous les contextes efficacement
- avoir un protocol stable et evolutif pour quelques decennies
Si on ajoute a cela que l'on veut suivre des use case generique et non pas se limiter a Unity, tout d'un coup cette demo perd beaucoup d'interet… Elle ne montre finalement qu'un compositeur limiter tournant en frame buffer.
Pour le troll, Canonical se prend pour Google et essaye de creer sa propre stack qu'elle controlera completement. Le developpement est fait tout seul dans son coin sans tenter d'avoir une communaute de developpeur externe. Enfin je te conseille de prendre ton laptop, installer une Ubuntu et faire un petit test avec powertop, puis installe une distrib un peu plus clean avec GNOME, KDE et Enlightenment. Regarde quel setup te faira gagner le plus de batterie…
[^] # Re: Excellent !
Posté par cedric . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. Évalué à 2.
Je parle de randonnee ici, avec sac a dos, tente or refuge ! Ca donne de tres belle vue, mais il vaut mieux planifier un rien son itineraire quand meme :-)
[^] # Re: Excellent !
Posté par cedric . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. Évalué à 2.
Il y a rarement un seul chemin pour faire 15km :-) Et la ou je fais de la randonnee, je passe un peu de temps a devoir regarder les cartes pour justement choisir le trace le plus interressant. Un mix de point de vue et d'optimisation de parcour.
# Excellent !
Posté par cedric . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. Évalué à 9.
Impressionnant comme boulot, openstreetmap est vraiment une plateforme qui a de plus en plus d'interet. Ca fait deux fois que je pars en vacances et que la meilleure cartographie est fournit par Openstreetmap et marche en plus offline ! J'aurais juste deux questions :
Est-ce qu'il serait possible d'en faire une version offline en recuperant juste la base de donnees Postgresql par exemple ? En gros, ton serveur Postgresql consomme combien de ram ? Et quel est la puissance processeur minimal necessaire pour resoudre un itineraire ?
Et tu aurais la meme chose en stock pour la randonnee ? :-)
[^] # Re: Weston utilisable...
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 2.
Il y a forcement toujours une cooperation entre l'application et le serveur. L'explication donnee sur le fait de retirer les buffer a l'application est aussi une mauvaise raison. Si tu retires un buffer a l'application, celle-ci ne doit pas etre entrain de l'utiliser, donc tu as forcement cooperation. Ensuite tu peux toujours bloquer le retour du prochain buffer cote server pour forcer un ralentissement de ton application, mais ca c'est aussi bien possible dans Mir que Wayland. Et dans le port Wayland via libhybris l'allocation est fait cote serveur…
Et pour ce qui est des chiffres de performance, je connais au moins une implementation de Wayland qui est 10% plus performante que SurfaceFlinger (le compositeur de Android) avec des drivers bien pourri. Ubuntu d'un autre cote sur mon PC est un goinfre energetique et ils ne sont pas trop repute de ce cote la. Sur mon Nexus 7, ca le rend juste inutilisable… Mais bon, on va leur laisser le benefice du doute pour l'instant, ca se trouve ils vont faire un truc techniquement bien pour une fois Ubuntu… On sait jamais !
[^] # Re: priorités?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à -1.
Il y a combien de RPi dans la nature ? Et ca represente quelle part du "desktop" Linux ? Il faut des fois mettre les choses en perspective, on n'est pas forcement representatif. Pour ceux qui en est de Mir, c'est incroyable la confiance aveugle que les gens peuvent avoir dans une solution faite par des gens qui ne connaissent rien a la realisation d'un compositeur graphique, la securite et les methodes d'input. C'est bien, ils apprendront, mais le resultat, a part etre la propriete de Ubuntu, n'aura d'interet pour personne.
[^] # Re: Et QT là dedans?
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 3.
En meme temps, ca ne dit pas quelle version du protocol est supporte. Je suis meme incapable de le dire pour les EFL… Et pourquoi cocorico pour les EFL ? On a certe la communaute la plus active en France. Mais on a plus d'utilisateur en Allemagne et les developpeurs sont repartis un peu de toutes les nationalites.
[^] # Re: Weston utilisable...
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 3.
C'est juste pas une raison technique du tout. Wayland ne definit pas ce qu'est un buffer et qui est en charge de l'allocation. Un buffer peut etre un truc genere par KMS/DRM, gralloc, malloc, voir meme un XPixmap. C'est juste du bullshit de leur part et ca a d'ailleur ete demontre par l'equipe de Sailfish qui fait tourner Wayland sur des drivers Android…
[^] # Re: Weston utilisable...
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 2.
Ca c'est encore pas tres evident. Il n'est pas clair pour l'instant de savoir si Mir s'appuiera sur KMS ou sur les driver Android ou les deux. Mais effectivement, ca a ete une rumeur. En meme temps, il leur reste un an avant de sortir un truc…
[^] # Re: Weston utilisable...
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 4.
Je ne sais pas ou tu as vu ca. Je n'ai pas entendu cette info de la part des devs qui sont passe sur les differents forums. Mais bon, mir est developpe dans son coin par ubuntu sans vraiment communiquer avec qui que ce soit…
# Weston utilisable...
Posté par cedric . En réponse à la dépêche X.Org est mort, vive Wayland ! (2). Évalué à 10.
Euh, juste comme ca, Weston n'est pas destine a etre utilise par madame Michu. C'est un validateur technologique du protocol Wayland. Il s'avere utilisable, mais son but n'est pas de remplacer Kwin, Enlightenment et consort. C'est a ces projets d'implementer le protocol Wayland et de fournir un desktop pour madame Michu. Weston sert a faire avancer les bibliotheques commune et a defricher le travail pour eux, mais ca laisse quand meme pas mal de boulot au dev de ces compositeurs.
Sinon mir semble ne pas avoir les meme objectifs que Wayland. Aussi bien en terme de performance, portabilite que de gestion de systeme d'input, mir ne semble pas du tout viser le cote generaliste de Wayland. Et pour le cout, aucun projet upstream ne va passer du temps dessus, donc il y a peut etre autant de dev sur Wayland que sur mir, mais upstream, il n'y en a pas. Et c'est toute la difference.
D'ailleur pour lancer un beau troll, il n'y a aucune justification technique a l'existence du protocol de mir. Ils auraient tres bien pu implementer leur compositeur Wayland sans plus de souci…
[^] # Re: On part de loin...
Posté par cedric . En réponse à la dépêche État des pilotes graphiques libres pour SoC. Évalué à 2.
Ah la comprehension des licenses en Asie. Tout un programme ! Si c'est un mtk, peut etre que ce que tu trouveras sur : http://www.wikogeek.com/ pourra t'aider. J'ai pas encore regarde, mais enormement de telephone asiatique utilise cette puce et il n'y a quasiment jamais de difference au niveau hard entre ces telephones.
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 3.
Et tu garantis comment le maintiens de 60fps quelque soit la charge de ta machine ? Il est juste certain qu'avec ton design, ca va lagge…
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 2.
Si tu me trouves une reference, je suis preneur (de preference, un truc que je peux faire marcher avec du soft libre ;-) )
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 2.
Le probleme de powertop, c'est qu'il mesure l'activite durant la decharge de la batterie. Si la batterie ne se decharge pas assez vite pour etre mesurer, alors il pense qu'il n'a pas consomme d'energie. En espacant au maximum les points de mesure, cela resoud le probleme… pour l'usage de powertop. Dans le cas d'un benchmark tel que celui-ci, je pense qu'il serait plus pertinent d'avoir une trace de la consomation en temps reel et qu'on puisse lq piloter en simultane de l'execution du benchmark. En gros, je cherche une sonde materiel qui puisse memoriser une trace et se faire piloter via usb.
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Desole, mais une interface en ncurse, ce n'est ni moderne ni joli. C'etait moderne dans les annees 70. Depuis, il y a eu Xerox, l'Apple II, XWindow et d'autre truc comme ca. C'est bien de troller, mais quand meme croire qu'il suffit de remplacer les quelques characteres colorise par des nimages pour avoir une interface moderne, c'est juste soit de la mauvaise fois, soit de l'incompetence. Vu qu'on est entrain de troller, je suis plus tenter par la premiere explication ;-)
[^] # Re: Pour ceux qui disent que GTK+ n'évolue plus...
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 10.
Oui. Portage vers Wayland, c'est juste ajoute un nouveau backend (creation de fenetre et recuperation des events) et regarder les problemes d'integration (vu qu'une partie de la gestion de fenetre est faite par l'application). Il n'y a pas de changement du modele de rendu, pas d'amelioration interne du toolkit. Et c'est necessaire pour la survie du toolkit sous Linux. Donc c'est de la maintenance. Pour le support des ecrans haute resolution, a part faire des graphismes plus fin, je vois meme pas ce que ca va changer dans le code !
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 2.
Faut pas oublier le lien vers le followup pour une comparaison dans l'embarque :
https://phab.enlightenment.org/phame/live/1/post/simple_efl_vs_qml_comparison_again/
J'aimerais bien faire une comparaison sur la consomation d'energie, mais je n'ai pas d'outil pour faire les mesures. Si quelqu'un a une idee.
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 0.
Ah, bah, trolldi est passe. Domage ;-)
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 4.
Non, je ne connais pas flare du tout.
Non, mais serieux, Ncurses quoi ! On parle d'interface graphique quand meme ! Parce que bon, c'est pas juste les degrades et les fioritures graphiques en moins, c'est toute l'ihm qui fait penser aux annees 80, la ! Sur que ca demande pas autant d'effort de pousser quelques characteres colorise face a des millions de pixels. Donc forcement, on n'a pas trop besoin de se poser de question. Et puis le cote asynchrone on s'en tappe un peu, les utilisateurs sont habitue a ce que ca bloque sur ce genre d'interface ! Quelle blague !
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -1.
J'aurais du faire une quote, parce que bon, la, ton argumentaire, c'etait: "parce que c'est plus utilise, c'est donc un meilleur choix". Maintenant tu en changes la comprehension…
Ca ne change rien a ce que j'ai dis. Les EFL tournent sur plus de materiel que wxWdiget ne pourra jamais le faire. C'est juste un fait. La portabilite des EFL fait que si ta machine n'est pas suffisante pour, alors tu peux oublier tous les autres framework. Apres qu'on ne garantisse pas l'equivalence de fonctionalite, en tant que logiciel libre, c'est un peu normal. C'est le boulot d'une societe de faire la partie QA. En temps que logiciel libre, on fait que ca marche bien pour notre usage et on resoud autant que possible les bugs rapporte par nos utilisateurs. D'ailleur je crois qu'on n'a pas besoin du support X11 pour OS X, elle n'est pas a jour cette page !
C'est marrant, mais je n'ai jamais utilise la moindre application fait avec wxWidgets. Tu m'aurais dis Qt, GTK, meme XUL, j'aurais dis OK, mais wxWidget, c'est vraiment pas le genre d'application que j'utilise. Et pourtant j'ai cherche dans la liste de leur site, mais nop. D'ailleur quand on voit la liste, c'est vraiment de l'institutionnel, pas vraiment un domaine que je croise souvent.
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 4.
Tres bien comme exemple Wesnoth. Le fait qu'il ne s'appuie pas sur un toolkit 2D performant fait qu'ils ont du reinventer pas mal de chose et contrairement a un projet dont c'est le but, ils sont loin d'etre aussi performant qu'il pourrait l'etre. Ils ont aussi du mal a pouvoir faire de l'OpenGL/OpenGL ES.
Avec un framework plus complet, ils auraient beneficie d'une boucle de rendu performante. D'un demarrage plus rapide en partageant des ressources avec le reste du systeme. Peut etre aussi une solution plus securise en separant le process qui charge les ressources du process principal.
Mais ils ont decide d'utiliser un toolkit plus simple. En fait, c'est un framework, mais juste plus bas niveau, la SDL. Pour le reseau, je ne pense pas me tromper en disant qu'ils utilisent SDL_Net. Donc ils ont bien utilise un framework. D'ailleur la SDL, n'est pas vraiment un toolkit graphique, vu que les primitives graphiques qu'elle fournit sont tres limite et que les applications doivent redevelopper quasiment toute leur boucle de rendu.
Pour FLTK, je n'ai aucune idee de ces limites, mais c'est aussi gros que les EFL. Donc pour un toolkit qui ne fait que l'IHM, tu "gagnes" pas grand chose..
[^] # Re: Trollons
Posté par cedric . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 9.
Tu fais comment la decompression d'image sans bloquer ta main loop. Tu fais comment l'upload de texture sans bloquer ta main loop. Tu fais comment le rendu d'une frame sans bloquer ta main loop. Donc oui, c'est necessaire d'avoir une bonne boucle d'evenement, mais ce n'est pas suffisant. Aujourd'hui faire un toolkit graphique performant sans utiliser de thread, ca va etre… comment dire… bloquant ! :-)