Tu es vieux jeu a vouloir le brancher ton telephone. Tu le poseras juste sur ton dock et hop wireless charging, WiGig pour l'ecran, l'audio out et le reseau, Bluetooth pour le clavier/souris et le micro/casque. Les telephones capablent de faire ca devrait exister dans environ 2 ans.
Quand a l'usage remplacement du desktop avec un dock. Tu prend un S3, il a une sortie HDMI et une connectique bluetooth. Ce qui limite, c'est le soft. Android n'a pas ete concu pour faire un PC, je me demande comment ils vont faire. Merge avec ChromeBook ? Dans tous les cas, le libre peut commencer a travailler aujourd'hui sur de tel interface. Et c'est ce que l'on fait en tout cas dans les projets Enlightenment et KDE.
Le plus gros probleme, c'est qu'on n'a pas aujourd'hui acces a du materiel avec les drivers libre ou compatible GNU/Linux. Android est le roi dans le domaine. Ca laisse peu de possibilite. Soit on reverse soit on construit une stack au dessus de Android. Resultat on va surement faire les deux, vu que ceux ne sont pas les meme personnes qui sont interresse !
Si vous avez envie de vous exercer au reverse engineering, trouver un telephone a base de Qualcomm ou d'Exynos et essayer de porter tous les drivers autres que 3D (Les projets Freedreno et Lima s'en occupant). Il y a deja pas mal de boulot.
Si vous avez envie de hacker Android, libhybris/libdrm et faire des backend pour pulseaudio, ophono, connman, bluez serait aussi tres utile. Logiquement les meme hard serait a privilegier histoire qu'on puisse facilement passer de la version surcouche a Android a la version completement libre.
Principalement parce que SurfaceFlinger est un projet a code ouvert que Google controle completement et destine uniquement a l'embarque (Google ne l'utilise pas sur ses ChromeBook). Wayland a l'oppose a ete concu pour pouvoir fonctionner sur toute la gamme des machines sur lequel un Linux tourne. Le protocol est le resultat de la cooperation de personne qui ont des annees d'experience avec X, les Window Manager, les Composite Manager, les drivers, les toolkits graphiques, en securite, en embarque … C'est un travail enorme et colossale qui a ete realise et il y a encore beaucoup a faire. La plus part des gens ne se rendent pas compte de l'ensemble des contraintes et des problemes a resoudre. La plus grande reussite de Wayland, c'est d'avoir reussi a attirer tous ces gens. Ce que ni SurfaceFlinger, ni DirectFB et pas non plus Mir a reussi a faire.
Quand on regarde la TODO de Mir, on se rend compte qu'ils n'ont meme pas encore attaque les sujets difficiles. Il y a un total manque d'experience de leur cote et ce projet va probablement avoir un destin funeste.
Il est comprehensible qu'ils se demarque de X, vu qu'ils ont du mal a monetiser leur plateforme Linux desktop et qu'il se tourne vers Android pour ca. Or cela veut dire se baser alors sur la stack graphique de Android. Je comprend en tout cas leur effort vers Mir comme un objectif de devenir une distribution Android. Mais bon, ils ont loupe que le protocol Wayland ne definit pas ce qu'est un buffer ID et que sous Android on aurait tres bien pu utiliser Gralloc. Il n'y a rien d'ailleur qui empeche d'ajouter un second protocol a son serveur Wayland pour gerer le protocol de SurfaceFlinger quand on est sous Android.
Il est tres probable que la plus part des implementations de Wayland implemente a terme plus que juste KMS. Ainsi avoir un backend fbcon est necessaire pour etre portable sur les BSD. Un backend XPixmap pour avoir acces au driver proprio NVidia. Donc un backend Android ne sera finalement plus que un backend supplementaire. Pourquoi pas aussi un backend SDL ? Et le code necessaire pour ses backend se limitera a peu de chose pres a gestion de buffer et lecture des inputs. Tout le reste du code etant commun a toutes les plateformes.
Si on demande les symboles de debug, c'est qu'on cherche un bug dans une bibliothèques. or le bug a probablement été résolu upstream, donc c'est pour ça qu'on récupère la branche stable du git / SVN pour trouver le problème.
Je critique les strategies multitache, car elles ont un impact sur l'utilisabilite du systeme et qu'elles ne sont pas necessaire. Je peux faire tourner un desktop avec 256Mo de RAM sans probleme. Pourquoi donc ce n'est pas possible sous Android ? Et probablement aussi avec Firefox Os. La reponse est simple. Chaque VM est completement isole, il y a peu de partage de donnees entre les process. Le toolkit ne favorise pas l'optimisation de la consommation memoire pour faire simple.
Qu'est-ce qu'on peut faire sous Linux de mieux, partage des ressources graphiques (image et font) entre tous les process par exemple. Ca permet entre autre de demarrer les applications plus rapidement, car les images sont deja charge en memoire. Avec Wayland on pourra meme directement s'organiser pour partager les buffers memoire et donc eviter de reuploader les pixels en double dans la carte graphique.
Ensuite quand on fait un systeme, on l'optimise pour un toolkit, celui-ci peut facilement fournir une mini application qui initialisera partiellement le toolkit et se preparera a faire juste un fork + dlopen au lieu de fork + exec. Le resultat, c'est le partage de quasiment toutes les pages memoires de tes bibliotheques plus une partie des donnees d'initialisation de ton toolkit. Ca ameliore d'autant le temps de demarrage d'une application. Il devient alors possible de demarrer une application meme sur un telephone bas de gamme avant que ton doigt ait quitte l'ecran.
Enfin, le multitache Android avec ses daemons en tache de fond est tellement bien foutu, que tes applications vont rapidement te tuer ta batterie. Mais bon, une societe qui pense que faire de l'http au dessus du reseau mobile est une bonne idee, faut pas trop en attendre non plus. Mon EEE PC tiens plus longtemps en utilisation que mon mobile en utilisation. Si on compare le suspend des deux, ca doit aussi etre a son avantage. Mais bon, tu n'utilise peut etre pas de la meme maniere un EEE PC que moi… Faut apprendre a comparer ce qui est comparable.
La raison pour laquelle, il n'y a rien sur le mobile, c'est parce qu'il faut des moyens. Trouve moi un telephone avec une stack complete jusqu'a Wayland ou X, avec tous les drivers d'operationnels et je suis sur que en moins de 6 mois tu auras un telephone Enlightenment ou Plasma Active. Et vu ta capacite a comprendre les contraintes techniques et les pre requis pour faire du developpement d'une interface, ca sert a rien que tu gagnes au Loto, de toute facon tu gaspilerrais l'argent.
C'est pas comme si il etait difficile de desactiver strip lors de la compilation d'un package. Et comme chacun le sait, on ne fait de debug sur une bibliotheque/application que en etant sur la derniere version git/svn. Donc de toute facon, on recompile et la Arch est vraiment top, paquet -svn/-git pour tout ce que j'utilise avant meme d'avoir a les ecrire. Franchement c'est le reve pour le developpeur.
le coût de la mémoire est quand même très faible (même sur mobile)
Le bas de gamme a 512Mo, le haut de gamme 1Go et le tres haut de gamme 2Go. Le probleme de la memoire, c'est sa consomation. Plus tu en augmentes la quantite, plus tu consommes d'energie. Plus ton application utilise de memoire, plus tu consommes d'energie. C'est aussi un facteur tres limitant du nombre d'application que tu peux lancer vu qu'il n'y a pas de swap sur un telephone.
Donc non la memoire a un cout non negligeable. Il y a un reel avantage competitif a l'utiliser efficacement et les constructeurs de telephones le savent. Et la situation n'est pas pret de changer. Les batteries et la memoire ne suivent pas la loi de Moore pour ce qui interresse les mobiles.
les tablettes ARM qui utilisent Java et qui sont pourtant plus performantes à l'utilisation.
Tablette ARM qui sont incapable de faire du multitache correctement. La ou j'avais sans souci sur mon eee, un browser, IRC, un client mail, un client jabber et quelque terminaux entrain de compiler. Je me retrouve avec un browser qui perd sans arret le contenu des pages que j'ai ouvert et qui les recharges. Un client mail qui prend du temps a se rafraichir, car il se recharge aussi completement. Un client IRC qui se fait deconnecter souvent…
Non, mon EEE est bien plus puissant que ma tablette et pourtant c'est un 701 alors que ma tablette c'est une nexus 7.
Linux a raté le desktop mais a réussi le mobile à la fois cotés client et serveur.
Un ratage a plus de 30 millions d'utilisateurs. Ca va. (Nombre d'utilisateur Ubuntu, donc probablement bien superieur).
GNU/Linux a raté le desktop et n'existera certainement jamais sur mobile quand on voit le conservatisme de ses utilisateurs.
Croire que l'existence de Linux sur le desktop ou le mobile est conditionne a la technique releve d'un manque cruel de comprehension du monde.
Ce qui fait que Linux a pu prendre dans le serveur, c'est que plein de petite societe ont pu facilement pousser leur solution commercial. Marche faiblement consomateur de capital avec beaucoup de marge.
Faire un desktop, c'est un marche a marge quasi nul et consomateur de quantite colossal de capital. En tout cas, si tu veux attaquer de front microsoft.
Faire un mobile, c'est un marche avec une bonne marge, mais il faut beaucoup de capital et en plus avoir ses entres chez tous les operateurs.
Tu en conclueras comme un grand que si Microsoft se fait deloger du PC se sera par Google Chrome OS et pas par GNU/Linux. Que la reussite de Android dans le mobile, c'est d'avoir fourni une solution clef en main support inclu pour les constructeurs de telephone.
Si tu as du capital, tu peux faire que GNU/Linux soit un succes sur mobile et sur desktop. Il y a quelques annees, j'avais vu les calculs de business plan pour faire un telephone bas de gamme, il faut 20 millions d'euros et 2 ans au minimum pour produire 30000 unites. Si tu les as n'hesite pas a faire un cheque ! Sinon tu te concentres sur la technique et tu fais en sorte que le vieux telephone que tu n'utilise plus puisse etre utilisable (ou ta tablette ou ton desktop).
D'ailleurs, Android utilise massivement Java et je n'ai pas l'impression que ça soit vraiment gênant.
C'est bien d'avoir des impressions. Le mieux c'est quand meme les fait et la realite !
Android part avec un gros handicap sur la consomation d'energie. Qt et les EFL consomment moins d'energie pour obtenir un resultat avec un frame rate plus eleve. Cela veut aussi dire que tu peux faire plus avec moins.
Mais bon, le marche du mobile ressemble de plus en plus au marche de l'informatique dans les annees 90. Une dizaine de nouveau OS, ca bouge beaucoup. Ca finira par se stabiliser sur l'un d'entre eux de maniere tres majoritaire et les constructeurs de telephone deviendront de simple OEM comme dans le monde du PC au bout de dix/quinze ans. Si ca continue de tourner comme le monde du PC, ca sera pas le meilleur techniquement qui s'en sortira, mais probablement celui qui aura la marque et l'approche commercial la plus efficace. Dans ce contexte Android est effectivement le mieux place et effectivement mettre du Java ou n'importe quoi d'autre n'aurait pas ete plus genant.
C'est comme la différence entre du C++ et du Java aujourd'hui. La perte de performances due à l'architecture de Java (machine virtuelle, fonctions toutes virtuelles, optimisations plus faibles) est négligeable pour la majorité des applications.
Tu en as de la chance. J'attend encore de trouver une application Java que j'utilise tous les jours… Ca fait dix ans que je l'attend. Au fait pour le negligeable, une difference entre iOS et Android vient entre autre qu'ils ont un toolkit natif qui est vraiment de tres bon niveau. C'est d'ailleur a leur desaventage, car les journalistes essayent toujours de comparer le hardware suivant les specs. Alors qu'il faudrait comparer la reactivite et la consomation d'energie…
Sans blagues… Mais à temps de développement égal, tu fais bien plus de choses en web. Tu peux t'amuser à réinventer la roue, mais personnellement je considère qu'il y a des gens qui l'on bien mieux fait que moi.
Vu le nombre de bibliotheque C qu'il existe, je suis pas sur que j'ai vraiment besoin de reinventer la roue si souvent.
En fait, j'ai l'impression que tu n'aimes pas le web et que tu aimerais que les utilisateurs préfèrent les CLI en C. Peut-être que tu considères que le design de ce type d'applications est plus beau. En attendant, l'utilisateur il aime bien cliquer sur un lien et que ça fonctionne.
Je prefere les applications qui reagissent instantanement quand je clique dessus. Je preferes une application qui se lance instantanement. Je preferes une application qui ne se croit pas seule au monde et laisse des ressources aux autres…
Etant developpeur Enlightenment, je prefere les UI EFL en C ou en JS. Mais je peux me faire a celle en Qt/QML a la rigueur. Par contre, les applis web, c'est juste quand je n'ai pas le choix. Et les applis Java, c'est jamais !
Ma reponse est peremptoire, car c'est un fait pour toutes personnes qui a un peu une connaissance de comment fonctionne un navigateur web et ce que ca represente. Et oui, le W3C fait un effort pour limiter l'incoherence du bordel, c'est bien d'avoir de la bonne volonte et il leur en faut !
Maintenant pour etre plus serieux, le web n'a pas ete concu pour le monde de l'embarque, tu le remarques assez facilement sur tous les navigateurs web Android. Aucun ne va etre capable de mettre tes pages web en standby et ils sont oblige de les recharger completement. C'est juste un exemple. Il y en a d'autre et tu en trouveras par toi meme.
Le plus gros probleme du Web et surtout dans les dernieres annees et d'avoir de plus en plus pris la direction du "baremetal" en exposant des API de rendu direct. Cela impose de mettre toute la logique du rendu dans le JS et non dans le C. En prenant cette direction, ils ont certe plus de souplesse et ca evite de definir une API d'un toolkit de haut niveau (qui serait a mon avis impossible a faire standardise). Par contre, maintenant, cela impose une enorme logique en JS avec tous les problemes de performance que cela pose. Et dans ce genre de morceau de code, le controle de la memoire est absolument crucial.
C'est en fait le point le plus problematique et que les gens ne saississent pas facilement. Certe la quantite de memoire augmente exponentiellement, vive Moore. Par contre sa latence et sa consomation ne suivent pas du tout cette courbe. Pour faire simple, plus tu utilises de memoire plus tu vas devoir eviter les acces aleatoires (difficile quand tu es a faire du JS) et aussi plus tu utilises de memoire plus tu utilises de batterie. Tu peux compter un rapport 10 entre chaque niveau de la hierarchie memoire aussi bien pour la latence que pour la consomation. Enfin, si jamais tu atteinds la bande passante memoire limite de ta machine, ton CPU va attendre et consommer plus que si il pouvait juste dormir.
Devine quoi, faire un rendu graphique a l'ecran tombe exactement dans ces taches qui sont aux limites de la bande passante memoire et pour lequel tout cela compte terriblement.
Accessoirement pour proposer une alternative, c'est simple tu prends un toolkit graphique natif et tu mets du JS dessus. Tu eviteras tous ces problemes. KDE, Enlightenment et je crois aussi GNOME, on ca en stock.
Et sinon qui je suis pour juger, je suis un developpeur du projet Enlightenment et j'ai une petite idee de comment ca marche le monde de l'embarque et le rendu de graphisme optimise.
La plupart des gens ont déjà des bouquins de recettes empilés dans un coin de la cuisine, même s'ils ne cuisinent pas vraiment. Acheter une tablette plusieurs centaines d'euros pour afficher une recette à la qualité douteuse trouvée sur le net, et la poser sur la table ou le bord de l'évier au milieu de l'eau, de la farine et de l'huile, il faudra vraiment m'expliquer qui d'autre qu'un geeko-bobo le fait…
Ok, oublions le cote tablette. Je cuisine pas mal et j'ai beaucoup de livre de cuisine. Ils me servent d'inspiration et me donnent des idees. Une fois que j'ai une idee, je vais cherche des recettes sur le meme sujet. J'en arrive a avoir un ensemble de recette qui sont suppose donner le meme resultat. Je peux alors comprendre quel est probablement la recette qui aura le meilleur resultat. Au final, je vais l'ecrire pour la memoriser et pouvoir la reproduire.
Le livre est une bonne source de navigation aleatoire (les photos comptent enormement), mais loin d'etre complet et la navigation est catastrophique. En plus, il faut rechercher dans plusieurs livres pour avoir les reponses. Le net par contre, c'est mauvais pour decouvrir des recettes au hazard, par contre la recherche et l'analyse croise sont nettement plus facile.
Par contre, je te rejoind sur les tablettes. Elles sont just inadapte pour un usage en cuisine. Il faut un affichage tete haute (meme le bouquin, c'est chiant ca prend de la place, une feuille avec un aimant c'est nettement plus pratique), ensuite si on veut pouvoir naviguer dans l'interface il faut soit de la reconnaissance vocale soit de la reconnaissance de geste, mais pas d'interface tactile.
Par contre Internet est une veritable source de recette et je me devais d'en prendre la defense juste pour remercier toutes les personnes qui prennent le temps de contribuer leurs recettes. D'ailleur en quoi une contribution a ces sites est differences en qualite aux contributions a Wikipedia ou au logiciel libre ?
Les problèmes de performances ne sont que temporaires. Je pense que d'ici quelques années, la différence de performances entre Dalvik (la machine virtuelle d'Android) et V8 (la machine virtuelle Javascript de Google) sera négligeable pour la majorité des applications.
Il y a quand meme des differences majeurs dans le language qui rendent juste impossible d'avoir la meme simplicite pour la compilation et si une tache est plus complique, elle prend plus de temps et reste forcement plus lent. Surtout que la compilation/optimisation, ce n'est pas une tache simple a la base…
Pour l'interface en elle même, la différence vient aussi du fait qu'il est possible de faire tout ce que l'on veut en web, alors qu'en natif on est limité aux choix des gens qui ont développé le toolkit.
Et ton interface web, elle tourne dans quoi ? Une application native :-D Tu peux faire logiquement plus en natif que avec du web. L'inverse etant faux !
C'est vrai que créer une application web aujourd'hui est plus pénible, mais ça vaut le coup. Car ton application Android ne fonctionnera que sur Android alors que ton application Web fonctionnera partout (enfin tout ce qui fait tourner webkit :p).
Pourtant Android, c'est du Java, c'est portable, ca marche partout ! Il y a dix ans, on me disait que ca serait vrai avec le Java… On avait les meme remarque, ca sert plus a rien de faire du natif, le Java resoud tous les problemes et il est plus rapide que le C… On m'a deja servi cette histoire, je ne vois pas ce qu'il y a de fondamentalement differement entre le monde Web et le monde Java. Quoique, les standards Web sont bien pire en terme de design que Java en fait. C'est 20 ans d'histoire et de hack sur une technologie qui n'a pas ete prevu pour ca, mais alors pas du tout !
Non, c'est faux. On a uniquement besoin de xshm pour les applications qui n'utilisent pas le GPU ou la pile graphique pour rendre son buffer. Les autres GPUs doivent utiliser GEM pour allouer et partager leurs buffers graphiques.
On parlait uniquement du cas software ici, donc on est d'accord :-)
D'après mon expérience, avec un compositeur software, quand je bouge une fenêtre, mon PC consomme 30W contre 9W en hardware. Tu parles de pas faire de copies tout le temps, mais un compositeur sw fait ça en permanence…
On n'a clairement pas le meme laptop :-) Le mien tourne a 7W quand je code avec le compositeur software de E17 et Terminology, ca monte a 9W avec le compositeur GL. Mais il n'utilise pas l'extention de partial swap de Intel, peut etre qu'en l'implementant cela changerait la donne. Le compositeur sw va faire une copie que des zones qui ont change, alors qu'en OpenGL, tu es oblige de tout redessiner a l'ecran (Donc tu fais plus de boulot et tu utilises plus de hard). Pour ce qui est des copies de buffer, elles sont inherente a X et on ne peut s'en passer que avec une extention te permettant de controller directement les buffers et la mise a jour partiel. Malheureusement, je n'ai pas ce genre de fonctionnalite sur mon laptop, uniquement sur du SoC ARM et je ne peux alors que te donner des chiffres de Android vs X.
Tu as utilise quoi comme compositeur sw, car a part E17, je n'en connais aucun autre ? Et non, llvmpipe n'est pas une reponse valable pour moi. C'est une solution completement inadapte pour faire un compositeur avec un minimum de performance. C'est bien pour tester une stack GL, mais pas pour autre chose.
Je te conseille vraiment d'étudier xdamage, ça devrait te prouver que tu as une mauvaise vision des flux entre les applications et X.
Je connais xdamage, merci :-) Et je pense que j'ai une petite idee de comment les flux passes entre X et les applications. Maintenant, j'ai clairement une experience plutot oriente SoC, donc avec des optimisations non disponible pour les GPU discrets.
Je trouve que tu as tendance à inventer des chiffres comme bon te semble, je me trompe? Si ton compositeur plante, met à jour ta distro car ça fait un bon moment que ça n'a arrive plus à part avec Nouveau si la carte est mal supportée.
Alors dans la vraie vie, les cartes a base de Radeon ont en general un driver bugge jusqu'a la moelle par exemple. C'est une des raisons pour lesquels avant de debugger le moindre bug report lie au compositeur dans Enlightenment, on demande sur quel carte graphique le probleme se pose. Pour l'histoire, fut un temps, le compositing ne pouvait marcher avec les drivers officiels de ATI que lorsque le process s'appele compiz… Et depuis, la situation ne s'est pas franchement ameliore chez eux. Chez NVidia, on n'a pas eu de probleme rapporte depuis quelques annees maintenant, mais leur driver genere des memcpy inutiles supplementaire qui font tourner le CPU pour rien lors de l'upload de texture entre autre chose (Je n'ai aucun retour d'utilisateur de Nouveau, ca veut dire que ca doit marcher :-)). Et chez Intel, ca semble etre bon avec les derniers drivers (Il y avait des dead lock en sorti de blank screen avant). Donc sauf a etre sur une Arch ou Gentoo, a peu pres personne n'a un driver correct.
Participant au developpement d'un compositeur, celui d'Enlightenment, j'ai une petite experience de l'etat du parc de driver posant probleme sur Linux. C'est sur, je ne vois que les gens qui viennent se plaindre ! Mais la situation est globalement mauvaise du cote des drivers Linux, c'est bien pour ca qu'il est succidaire de s'appuyer uniquement sur un compositeur hardware.
Le développeur principal de Wayland travaille chez Intel, tu crois vraiment qu'il ferait un truc pas utilisable sur leur plateforme?
Il va falloir que je me remette a jour sur Wayland, mais ma comprehension du truc, c'est que l'application controle les buffers et qu'elle peut faire du double buffer en utilisant une combinaison de wl_surface_attach, wl_surface_damage et wl_surface_commit. Ce qui devient un chemin sans copie sur SoC, et se resoud par un DMA vers le GPU cote serveur Wayland sur un GPU discret. Mais ca, c'est dans mes souvenirs, ca fait bien un an que je n'ai pas regarde. Ca serait domage que ce ne soit plus le cas.
SHM ne nécessite pas de copie en soit. C'est juste du partage de pages mémoire physiques. Du coup, je suis pas sûr de saisir ce que tu veux dire.
Vu que tu travailles plutot avec des GPU discret, la copie dont je parle se fait a coup de DMA dans ce cas la et est effectivement impossible a eviter sur ces GPU.
C'est assez étonnant d'entendre parler de SoC Intel car la mémoire est toujours séparée, tout comme le chipset et les deux sont toujours indispensable.
Hum, en fait, je n'ai jamais regarde en detail les i7 et i5 avec GPU integre, mais de ce que j'ai compris sur leur SoC, tu partage le meme controleur memoire. Certe tu dois negocier avec le GPU pour mapper la memoire dans l'adresse space du CPU. Mais cela devient directement accessible et ne genere pas de copie quand tu "unmap" ta memoire pour la rendre de nouveau utilisable par le GPU. Tu peux donc avoir ton rendu software qui va cycler sur un certain nombre de buffer directement utilisable par le GPU. Je n'ai pas travaille assez longtemps sur SoC Intel pour etre sur du comportement, mais sur SoC Qualcom et Samsung, tu as clairement ce comportement. Je soupsonne que c'est le cas pour toutes les SoC qui supporte Android.
Mais au fond, tu veux en venir où? Ce que tu proposes est sous optimal dans pratiquement tous les cas, et ne change rien dans d'autres (GPU avec mémoire partagée only).
C'est clairement sous optimal avec un GPU discret, donc il faut forcement garde le chemin avec xshm pour ce cas la. Pour les GPU a memoire partage, tu gagnes une copie memoire, ce qui a un impact direct sur les performances et se repercute principalement sur la consomation de la batterie (Le hard moderne tenant facilement les 60fps, c'est surtout la batterie qui montre les soucis de performance). Ce qui est logique, car toute operation que tu ne fais pas, ne consome pas de batterie :-) D'un point de vue difference, une stack X qui fait du xshm vs Android consomme plus de batterie aux environs de 30% (Mais ce chiffre dependra de ce que tu benchmark bienentendu).
C'est parfaitement possible de mixer le rendu logiciel et hardware. Cela dit, avoir une appli accélérée mais un compositeur software, ça me semble stupide. Tu as un cas en tête?
Parce que la majorite des drivers OpenGL ne sont pas capable de tenir un mois sans cracher en faisant du compositing ? Je n'ai besoin de basculer mon compositeur en OpenGL que lorsque je fais du multiscreen. Et j'economise aussi de la batterie a reste en soft quand je code, car au lieu de redessiner tout l'ecran, il ne met a jour qu'un tout petit coin. Mais vu que je fais souvent de l'OpenGL, c'est pas mal de pouvoir quand meme avoir ce cas qui marche… Et ca, c'est sur un desktop, sur une tablette ou un telephone, le cas se presente encore plus frequement (consomation eleve de memoire du au context OpenGL, switch de context entre le compositeur et l'appli qui n'est pas forcement un moment joyeux, …).
Sinon de nos jours, c'est les GPU discrets qui sont en "voit" de disparition face au GPU a memoire integre. Comparer le nombre de Linux dans un cas et dans l'autre est d'ailleur assez vite fait ! Plus d'un million sont active par jour avec une memoire partage… Et Wayland ainsi que le futur de Linux se trouve dans ce domaine la, donc il faut que ce cas soit optimisable.
Alors, ce que tu dis est une possibilité. Wayland supporte en effet ce qui était l'extension XDamage. Cependant, on est pas obligé de l'utiliser! Dans une vidéo ou un jeu vidéo, il vaut mieux ne pas se faire chier avec ça!
Ce qui reste un cas particulier avec un seul rectangle :-) Tu me l'accordera, mais tu passes quand meme pas mal de temps devant ton ecran a regarder des applications statiques ou seule un petit curseur de 10 par 20 pixels clignotes. Si tu travailles sur ton laptop avec un compositing et des applications incapable de faire du partial update, tu vas y perdre une bonne partie de ta batterie a rien faire d'autre que de redessiner la meme chose a l'ecran. C'est d'ailleur une des optimisations d'Android, les applis sont en rendu direct la plus part du temps et font au tant que possible du partial update. La difference de consommation avec un X/Toolkit classique qui ne fait pas attention est de l'ordre de 50% de conso supplementaire sur des simples zone de texte qui clignote par exemple.
Je ne suis pas d'accord. Changer X en Wayland, c'est casser la compatibilité avec la majorité des applications X actuelles.
Je me suis peut etre pas exprime assez clairement. Mais il est completement possible d'implementer au niveau des compositeurs X, l'equivalent de ce que fait le protocol Wayland. C'est d'ailleur surement le chemin que vont suivre la plus part des desktops linux en implementant Wayland en parallele de leur compositeur X. Bien entendu, ca, c'est en oubliant le probleme de securite. Mais l'interet sera d'avoir une adoption plus rapide de Wayland et un test grandeur nature des limites du protocol aussi. Il y a encore quelques trucs necessaire pour faire un desktop Linux complet avec Wayland et tant que ce ne sera pas la, ca avancera doucement.
Hmm, actuellement, les buffers ne sont pas copiés dans le cas de DRI2 et, pour les applis 2D, à priori, ils utilisent xshm. Ça permet de référencer/partager des buffers sans les copier. Dans Wayland, le même protocole existe (c'est même le seul chemin autorisé) et il ne faut pas espérer quel que soit d'autre.
Xshm te donne une position et une taille, donc il y a bien une copie a ce moment la. Si tu as un GPU discret (discrete GPU ?), c'est effectivement une bonne chose de ne pas reuploader toute ta fenetre et de t'appuyer sur un DMA pour faire la copie. Par contre, si tu es sur la meme memoire, cas des SoC et de Intel, il vaudrait mieux completement eviter le DMA en accedant directement a la surface video. La plupart des SoC et Intel supporte de faire les operations depuis une surface non tile/compresse avec une faible perte de performance qui dans la pratique devient un gain du fait de l'absence de copie et de cas de rendu direct (pas de compositing, car fenetre au dessus ou plein ecran).
Par contre, ton point sur Wayland m'ennuie. Je sais que la partie rendu soft n'est pas vraiment au point (quid d'une appli OpenGL avec un compositing software par exemple). Mais bon, dans le pire des cas, tu dois pouvoir utiliser l'api EGL en maintenant le rendu en soft pour obtenir le meme resultat, non ?
Ah ah, très très mauvaise idée :D Déjà, toute la VRAM n'est pas accessible au CPU. De deux, il y a des tonnes de formats de tilling et de compression. C'est chercher la merde que d'essayer de faire un accès CPU dessus. Et pour finir, c'est lent! Il vaut mieux utiliser les moteurs de copies asynchrones proposés par le GPU.
Les GPU Intel et la plupart des SoC tombe pourtant dans cette categorie. Apres c'est vrai que pour NVidia et ATI, ce n'est pas le cas, mais c'est pas la majeur partie du parc. C'est bien pour ca que j'avais fait une petite liste de condition ;-)
Si les Enlightenment Foundation Library font tout a fait ca ! L'inconvenient est que le code de redimensionnement des fenetres X avec OpenGL est particulierement lent (on peut limite compter en seconde). Cela limite donc son utilisation a des machines types telephone, tablette ou tv. La ou l'utilisateur ne peut pas jouer avec la taille de la fenetre.
En general avec de l'ATI, tu pars quand meme avec un bon handicap… Tu peux toujours tenter des environnements plus leger, mais il ne faut pas croire au miracle.
Avec wayland, ça ira encore plus vite car on aura même plus besoin de sérialiser les commandes ou l'image finale dans une socket et traiter le rendu de toutes les applis dans une thread unique (X).[coupé] Plus de sérialisation du rendu, plus d'utilisation d'un toolkit 2D très limité (X11/XRender).
Il me semble que dans le mode Qt/raster ou OpenGL(DRI2), il n'y ni sérialisation, ni utilisation d'un toolkit 2D puisque dans les 2 cas, le client peut écrire dans son buffer lui-même et envoyer le résultat par mémoire partagée(Qt raster) ou buffer vidéo (DRI2), non?
Il reste que le protocol X (Xlib ou Xcb) est toujours serialise dans une socket. Ok, il y a moins de requete dedans, si on n'utilise pas Xrender, mais ca n'empeche que le cout de la serialisation dans un socket est la. Une amelioration simple serait d'utiliser un buffer shm pour communiquer avec X et de n'envoyer dans la socket que l'index ou commence dans le buffer shm de la serie de commande X. Cela serait plus efficace a mon avis pour les communications locales. Je me demande d'ailleur, comment est implementer cette partie la du protocol Wayland, je crois que ca passe tout dans la socket.
Par mémoire partagé, pour sûr. Par BO, je doute, à vérifier. Dans le cas de la mémoire partagée, c'est sous optimal comparé à l'utilisation de buffers GEM car la mémoire partagée nécessite au minimum de placer le buffer partagé dans la GART ce qui est lent et augmente la pression sur cette zone. Dans le cas de buffers GEM, ils sont probablement déjà en VRAM, donc ça va plus vite :)
Ca depend. Si on fait du rendu soft, que le GPU utilise la meme memoire que le CPU et que le backend soft comprend le format du GPU alors oui. Sinon la vie est plus complique.
La grosse amelioration de Wayland, c'est surtout le control du buffer video par l'application. Avec X, meme lorsqu'on evite d'utiliser Xrender pour le rendu, on est encore force d'uploader des buffers de pixels via xshm. Cela genere des memcpy inutile. Avec Wayland, l'application/le toolkit utilise deux buffers video et fait automatiquement les delta sur deux frames. Cela evite le memcpy inutile.
Mais techniquement, il n'y a rien la dedans qui ne serait pas impossible a faire avec X. En fait pour obtenir les meme perf, il suffirait de pas grand chose dans DRI (peut etre dans la version 3). Support de la mise a jour partiel et recuperation des buffers d'une fenetre. Du cote compositeur, il n'y a pas de changement a faire. Ce genre de fonctionalite serait aussi tres utile dans OpenGL, Intel a une extention pour ca, mais ca marche moyen.
Donc on peut encore corriger X pour etre aussi efficace que Wayland… Le seul truc qu'on ne peut pas, c'est le rendre sur. Ca, c'est la seule chose impossible sans changement d'architecture et c'est vraiment la ou Wayland vaut le cout.
C'est sur Bill et ses 640K, il pouvait pas aller bien loin… Non, tu es serieux avec tes 25k ? C'est absolument enorme comme taille ! Deja 2K, c'est considere comme etant un peu obese, mais la juste 10 fois plus et ca ne te fais pas sourciller…
J'ai ouvert un Firefox avec extensions désactivées, et avec 5 onglets de sites divers et variés (doc php, linuxfr, site de news, twitter etc…). J'ai ouvert les mêmes onglets dans Chromimum (sans extension). Résultat : j'ai la même occupation mémoire qui est de 150Mo.
Et si tu testais avec une application native… Non, parce que le souci, c'est le standard qui rend difficile toutes optimisations. Un claws-mail vs GMail sur Firefox ou Chromium, ca donne quoi chez toi ? Chez moi, c'est clairement a l'avantage de claws-mail, et pourtant c'est pas l'archetype du machin optimise et ils n'ont pas les ressources Google ou Mozilla pour optimiser tout ca.
Le probleme n'est pas Firefox ou Chrome, mais le standard lui meme qui pousse a la consomation de ressource et dont on peut difficilement voir pas du tout, faire le tour.
Ça veut rien dire. Les sites de nos jours sont gourmands.
Si mon gmail prend plus de memoire que mon claws-mail, ca veut dire quelque chose !
Je trouve bizarre de parier sur quelque chose dont tu ne connais rien : le matos qui sera utilisé, la pile graphique utilisée, le fonctionnement du moteur de rendu etc..
J'ai suffisament d'experience sur comment optimiser un pipeline de rendu graphique et sur le materiel disponible pour les constructeurs de telephone pour estimer pouvoir prendre ce parie. J'ai une idee assez precise de ce qu'on peut avoir et pour quel prix. Il y aura forcement draw back a leur choix.
Je ne comprend pas de quoi tu parles là… Le rendu graphique n'est pas en JS. De plus y a du JIT dans le moteur JS de Firefox…
Encore heureux que le rendu graphique ne soit pas en JS ! Mais si tu as un jour code un pipeline graphique, tu saurais que la plus grande difficulte est dans le scene graph qui est en charge de gerer les requetes au code de rendu direct. Ce code la est massivement code en JS (exemple le petit lien plus haut sur facebook…). Et le JIT ne t'aidera pas beaucoup par rapport a du natif, car tu as un certain nombre d'optimisation impossible du fait de l'impossibilite de manipuler la memoire directement. Cela bien entendu en partant du principe que ton JIT et ton toolkit JS se comprenne bien…
Ce n'est pas un domaine trivial que de reussir a optimiser ton code non type sans gestion de la memoire pour qu'il soit proche en terme de vitesse de ce qu'on fait en natif de maniere naive. Et tout comme le Java pendant la derniere decennie, le JS, dont le JIT est fait au runtime, sera forcement toujours plus lent que du code natif au petit oignon. Et oui, les toolkits natifs font de gros effort sur ces morceaux de code.
Tu sais que plus de 60% des transactions a la bourse de New York sont le fruit d'operation completement automatique et sans aucune intervention humaine autre que la programation du dit algorithm ? On appel ca le High Frequency Trading… Ah oui, on est en 2013 apperement !
Rassures-moi, la dernière fois que tu as utilisé Firefox, c'était la version 3.6 non ?
Desole, 17.0.
Bon en tout cas, tu aurais pu éviter de troller, on n'est pas vendredi. Les dernières versions de Firefox sont particulièrement économes en mémoire et rapides.
Peut etre qu'on n'a pas la meme definition de econome en fait. Pour 4 tab ouvert, j'ai 240Mo qui disparaisse…
Firefox OS, c'est un noyau linux, un gecko au dessus, et un bureau en HTML5/JS. Et c'est fait pour des téléphones lowcost. Et je peux t'assurer que ça reste véloce sur les prototypes bas de gamme que j'ai eu entre les mains.
C'est deja un bon debut que ca fasse du 60 fps tout le temps. On est en 2013 et on a des SoC couillu meme dans le low cost de nos jours. Par contre, ce qu'on remarque moins directement c'est la consomation de la batterie. Je te propose un jeu. Implemente un simple test qui scroll de haut en bas en boucle en affichant du texte et des images. Fait le meme rendu sur Android. Fait ensorte que chacun tienne ses 60FPS. Prend maintenant ton wattmetre et mesure. Je suis pret a parier que Firefox OS est au dessus en conso ou au mieux au meme niveau.
A titre d'indication, avec les EFL et un bon driver X, on est a une conso 2 fois moindre que Android (ca implique que tu peux prendre un CPU/GPU deux fois moins puissant ou que ton telephone aura une plus grande autonomie). Je pense que Qt doit se situer entre les deux etant donnee que leur scenegraph n'a pas eu autant le temps de s'optimiser.
La raison pour laquelle je pense que Firefox OS va avoir des problemes de performance, c'est qu'il deporte la resolution du souci plus haut dans la stack. Il faut utiliser un toolkit JavaScript qui soit malin et optimiser pour que son appli ne rame pas. Ce qui veut dire que dans le meilleur des cas, le boulot est fait en JS pour le chemin critique. Hors en JS, tout comme en Java, tu n'as aucun controle sur l'allocation memoire et tu ne peux pas maitriser ton cycle memoire. Or en terme de performance, a partir du moment ou tu as un scenegraph (avec OpenGL ou software), la maniere et la quantite de memoire que tu manipules devient critique et a un impact direct sur le resultat. Bien entendu, ca c'est quand tout le monde code super bien en HTML/JS et utilise le bon toolkit bien optimise pour que tout se passe bien…
Les smartphones sont dominés par une course vers la réduction des prix, et à moins d'avoir une armée d'ingénieurs aussi grande que Google + friends, j'ai du mal à voir ce que Canonical va faire face à Google qui fait presque de la vente à perte.
Si ton moteur graphique est ecrit en C/C++, tu as des le depart un avantage majeur sur Google. Le principal probleme, c'est que pour avoir des perfs, il te faut maitriser ton allocation memoire au maximum et ca, en faisant ton moteur dans une VM, tu l'as perdu !
Par contre, le vrai probleme de Ubuntu, c'est qu'ils sont tres mauvais sur les quantites de RAM dont ils ont besoin pour fonctionner. J'espere pour eux qu'ils ont un plan pour resoudre ce probleme. Le probleme etait dramatique sur Nexus 7/Ubuntu, il ne restait plus que 300M pour les applications sur 1Go.
Je n'ai pas plus de mesure sur Qt et Ubuntu, mais faire un toolkit qui consomme moins de memoire, CPU/GPU et batterie que Android… c'est faisable par une petite equipe. Les EFL consomment a performance graphique equivalente 50% de moins en batterie. Elles n'ont pas besoin de GPU et consomme aussi moins de memoire. Partir d'un bon design, evite d'avoir besoin d'une armee titanesque pour resoudre le probleme ! ;-) Et d'un point de vue design, QML/SceneGraph est sur les traces de ceux que font les EFL, donc ils doivent potentiellement avoir le meme avantage a terme.
[^] # Re: L'Histoire se répète.
Posté par cedric . En réponse au journal Windows 8, échec responsable de la baisse des ventes de PC, Microsoft condamné. Évalué à 6.
Tu es vieux jeu a vouloir le brancher ton telephone. Tu le poseras juste sur ton dock et hop wireless charging, WiGig pour l'ecran, l'audio out et le reseau, Bluetooth pour le clavier/souris et le micro/casque. Les telephones capablent de faire ca devrait exister dans environ 2 ans.
Quand a l'usage remplacement du desktop avec un dock. Tu prend un S3, il a une sortie HDMI et une connectique bluetooth. Ce qui limite, c'est le soft. Android n'a pas ete concu pour faire un PC, je me demande comment ils vont faire. Merge avec ChromeBook ? Dans tous les cas, le libre peut commencer a travailler aujourd'hui sur de tel interface. Et c'est ce que l'on fait en tout cas dans les projets Enlightenment et KDE.
Le plus gros probleme, c'est qu'on n'a pas aujourd'hui acces a du materiel avec les drivers libre ou compatible GNU/Linux. Android est le roi dans le domaine. Ca laisse peu de possibilite. Soit on reverse soit on construit une stack au dessus de Android. Resultat on va surement faire les deux, vu que ceux ne sont pas les meme personnes qui sont interresse !
Si vous avez envie de vous exercer au reverse engineering, trouver un telephone a base de Qualcomm ou d'Exynos et essayer de porter tous les drivers autres que 3D (Les projets Freedreno et Lima s'en occupant). Il y a deja pas mal de boulot.
Si vous avez envie de hacker Android, libhybris/libdrm et faire des backend pour pulseaudio, ophono, connman, bluez serait aussi tres utile. Logiquement les meme hard serait a privilegier histoire qu'on puisse facilement passer de la version surcouche a Android a la version completement libre.
[^] # Re: Quelques infos
Posté par cedric . En réponse au journal Mir, un serveur d'affichage de trop ?. Évalué à 10.
Principalement parce que SurfaceFlinger est un projet a code ouvert que Google controle completement et destine uniquement a l'embarque (Google ne l'utilise pas sur ses ChromeBook). Wayland a l'oppose a ete concu pour pouvoir fonctionner sur toute la gamme des machines sur lequel un Linux tourne. Le protocol est le resultat de la cooperation de personne qui ont des annees d'experience avec X, les Window Manager, les Composite Manager, les drivers, les toolkits graphiques, en securite, en embarque … C'est un travail enorme et colossale qui a ete realise et il y a encore beaucoup a faire. La plus part des gens ne se rendent pas compte de l'ensemble des contraintes et des problemes a resoudre. La plus grande reussite de Wayland, c'est d'avoir reussi a attirer tous ces gens. Ce que ni SurfaceFlinger, ni DirectFB et pas non plus Mir a reussi a faire.
Quand on regarde la TODO de Mir, on se rend compte qu'ils n'ont meme pas encore attaque les sujets difficiles. Il y a un total manque d'experience de leur cote et ce projet va probablement avoir un destin funeste.
Il est comprehensible qu'ils se demarque de X, vu qu'ils ont du mal a monetiser leur plateforme Linux desktop et qu'il se tourne vers Android pour ca. Or cela veut dire se baser alors sur la stack graphique de Android. Je comprend en tout cas leur effort vers Mir comme un objectif de devenir une distribution Android. Mais bon, ils ont loupe que le protocol Wayland ne definit pas ce qu'est un buffer ID et que sous Android on aurait tres bien pu utiliser Gralloc. Il n'y a rien d'ailleur qui empeche d'ajouter un second protocol a son serveur Wayland pour gerer le protocol de SurfaceFlinger quand on est sous Android.
Il est tres probable que la plus part des implementations de Wayland implemente a terme plus que juste KMS. Ainsi avoir un backend fbcon est necessaire pour etre portable sur les BSD. Un backend XPixmap pour avoir acces au driver proprio NVidia. Donc un backend Android ne sera finalement plus que un backend supplementaire. Pourquoi pas aussi un backend SDL ? Et le code necessaire pour ses backend se limitera a peu de chose pres a gestion de buffer et lecture des inputs. Tout le reste du code etant commun a toutes les plateformes.
[^] # Re: Pourquoi ?
Posté par cedric . En réponse au journal x2go : le digne successeur de freenx. Évalué à 1.
Si on demande les symboles de debug, c'est qu'on cherche un bug dans une bibliothèques. or le bug a probablement été résolu upstream, donc c'est pour ça qu'on récupère la branche stable du git / SVN pour trouver le problème.
[^] # Re: Le web comme machine virtuelle ...
Posté par cedric . En réponse au journal Les vieux cons et le progrès…. Évalué à 3.
Je critique les strategies multitache, car elles ont un impact sur l'utilisabilite du systeme et qu'elles ne sont pas necessaire. Je peux faire tourner un desktop avec 256Mo de RAM sans probleme. Pourquoi donc ce n'est pas possible sous Android ? Et probablement aussi avec Firefox Os. La reponse est simple. Chaque VM est completement isole, il y a peu de partage de donnees entre les process. Le toolkit ne favorise pas l'optimisation de la consommation memoire pour faire simple.
Qu'est-ce qu'on peut faire sous Linux de mieux, partage des ressources graphiques (image et font) entre tous les process par exemple. Ca permet entre autre de demarrer les applications plus rapidement, car les images sont deja charge en memoire. Avec Wayland on pourra meme directement s'organiser pour partager les buffers memoire et donc eviter de reuploader les pixels en double dans la carte graphique.
Ensuite quand on fait un systeme, on l'optimise pour un toolkit, celui-ci peut facilement fournir une mini application qui initialisera partiellement le toolkit et se preparera a faire juste un fork + dlopen au lieu de fork + exec. Le resultat, c'est le partage de quasiment toutes les pages memoires de tes bibliotheques plus une partie des donnees d'initialisation de ton toolkit. Ca ameliore d'autant le temps de demarrage d'une application. Il devient alors possible de demarrer une application meme sur un telephone bas de gamme avant que ton doigt ait quitte l'ecran.
Enfin, le multitache Android avec ses daemons en tache de fond est tellement bien foutu, que tes applications vont rapidement te tuer ta batterie. Mais bon, une societe qui pense que faire de l'http au dessus du reseau mobile est une bonne idee, faut pas trop en attendre non plus. Mon EEE PC tiens plus longtemps en utilisation que mon mobile en utilisation. Si on compare le suspend des deux, ca doit aussi etre a son avantage. Mais bon, tu n'utilise peut etre pas de la meme maniere un EEE PC que moi… Faut apprendre a comparer ce qui est comparable.
La raison pour laquelle, il n'y a rien sur le mobile, c'est parce qu'il faut des moyens. Trouve moi un telephone avec une stack complete jusqu'a Wayland ou X, avec tous les drivers d'operationnels et je suis sur que en moins de 6 mois tu auras un telephone Enlightenment ou Plasma Active. Et vu ta capacite a comprendre les contraintes techniques et les pre requis pour faire du developpement d'une interface, ca sert a rien que tu gagnes au Loto, de toute facon tu gaspilerrais l'argent.
[^] # Re: Pourquoi ?
Posté par cedric . En réponse au journal x2go : le digne successeur de freenx. Évalué à 2.
C'est pas comme si il etait difficile de desactiver strip lors de la compilation d'un package. Et comme chacun le sait, on ne fait de debug sur une bibliotheque/application que en etant sur la derniere version git/svn. Donc de toute facon, on recompile et la Arch est vraiment top, paquet -svn/-git pour tout ce que j'utilise avant meme d'avoir a les ecrire. Franchement c'est le reve pour le developpeur.
[^] # Re: Le web comme machine virtuelle ...
Posté par cedric . En réponse au journal Les vieux cons et le progrès…. Évalué à 9.
Le bas de gamme a 512Mo, le haut de gamme 1Go et le tres haut de gamme 2Go. Le probleme de la memoire, c'est sa consomation. Plus tu en augmentes la quantite, plus tu consommes d'energie. Plus ton application utilise de memoire, plus tu consommes d'energie. C'est aussi un facteur tres limitant du nombre d'application que tu peux lancer vu qu'il n'y a pas de swap sur un telephone.
Donc non la memoire a un cout non negligeable. Il y a un reel avantage competitif a l'utiliser efficacement et les constructeurs de telephones le savent. Et la situation n'est pas pret de changer. Les batteries et la memoire ne suivent pas la loi de Moore pour ce qui interresse les mobiles.
Tablette ARM qui sont incapable de faire du multitache correctement. La ou j'avais sans souci sur mon eee, un browser, IRC, un client mail, un client jabber et quelque terminaux entrain de compiler. Je me retrouve avec un browser qui perd sans arret le contenu des pages que j'ai ouvert et qui les recharges. Un client mail qui prend du temps a se rafraichir, car il se recharge aussi completement. Un client IRC qui se fait deconnecter souvent…
Non, mon EEE est bien plus puissant que ma tablette et pourtant c'est un 701 alors que ma tablette c'est une nexus 7.
Un ratage a plus de 30 millions d'utilisateurs. Ca va. (Nombre d'utilisateur Ubuntu, donc probablement bien superieur).
Croire que l'existence de Linux sur le desktop ou le mobile est conditionne a la technique releve d'un manque cruel de comprehension du monde.
Ce qui fait que Linux a pu prendre dans le serveur, c'est que plein de petite societe ont pu facilement pousser leur solution commercial. Marche faiblement consomateur de capital avec beaucoup de marge.
Faire un desktop, c'est un marche a marge quasi nul et consomateur de quantite colossal de capital. En tout cas, si tu veux attaquer de front microsoft.
Faire un mobile, c'est un marche avec une bonne marge, mais il faut beaucoup de capital et en plus avoir ses entres chez tous les operateurs.
Tu en conclueras comme un grand que si Microsoft se fait deloger du PC se sera par Google Chrome OS et pas par GNU/Linux. Que la reussite de Android dans le mobile, c'est d'avoir fourni une solution clef en main support inclu pour les constructeurs de telephone.
Si tu as du capital, tu peux faire que GNU/Linux soit un succes sur mobile et sur desktop. Il y a quelques annees, j'avais vu les calculs de business plan pour faire un telephone bas de gamme, il faut 20 millions d'euros et 2 ans au minimum pour produire 30000 unites. Si tu les as n'hesite pas a faire un cheque ! Sinon tu te concentres sur la technique et tu fais en sorte que le vieux telephone que tu n'utilise plus puisse etre utilisable (ou ta tablette ou ton desktop).
[^] # Re: Le web comme machine virtuelle ...
Posté par cedric . En réponse au journal Les vieux cons et le progrès…. Évalué à 8.
C'est bien d'avoir des impressions. Le mieux c'est quand meme les fait et la realite !
Android part avec un gros handicap sur la consomation d'energie. Qt et les EFL consomment moins d'energie pour obtenir un resultat avec un frame rate plus eleve. Cela veut aussi dire que tu peux faire plus avec moins.
Mais bon, le marche du mobile ressemble de plus en plus au marche de l'informatique dans les annees 90. Une dizaine de nouveau OS, ca bouge beaucoup. Ca finira par se stabiliser sur l'un d'entre eux de maniere tres majoritaire et les constructeurs de telephone deviendront de simple OEM comme dans le monde du PC au bout de dix/quinze ans. Si ca continue de tourner comme le monde du PC, ca sera pas le meilleur techniquement qui s'en sortira, mais probablement celui qui aura la marque et l'approche commercial la plus efficace. Dans ce contexte Android est effectivement le mieux place et effectivement mettre du Java ou n'importe quoi d'autre n'aurait pas ete plus genant.
[^] # Re: Le web comme machine virtuelle ...
Posté par cedric . En réponse au journal Les vieux cons et le progrès…. Évalué à 10.
Tu en as de la chance. J'attend encore de trouver une application Java que j'utilise tous les jours… Ca fait dix ans que je l'attend. Au fait pour le negligeable, une difference entre iOS et Android vient entre autre qu'ils ont un toolkit natif qui est vraiment de tres bon niveau. C'est d'ailleur a leur desaventage, car les journalistes essayent toujours de comparer le hardware suivant les specs. Alors qu'il faudrait comparer la reactivite et la consomation d'energie…
Vu le nombre de bibliotheque C qu'il existe, je suis pas sur que j'ai vraiment besoin de reinventer la roue si souvent.
Je prefere les applications qui reagissent instantanement quand je clique dessus. Je preferes une application qui se lance instantanement. Je preferes une application qui ne se croit pas seule au monde et laisse des ressources aux autres…
Etant developpeur Enlightenment, je prefere les UI EFL en C ou en JS. Mais je peux me faire a celle en Qt/QML a la rigueur. Par contre, les applis web, c'est juste quand je n'ai pas le choix. Et les applis Java, c'est jamais !
[^] # Re: Le web comme machine virtuelle ...
Posté par cedric . En réponse au journal Les vieux cons et le progrès…. Évalué à 10.
Ma reponse est peremptoire, car c'est un fait pour toutes personnes qui a un peu une connaissance de comment fonctionne un navigateur web et ce que ca represente. Et oui, le W3C fait un effort pour limiter l'incoherence du bordel, c'est bien d'avoir de la bonne volonte et il leur en faut !
Maintenant pour etre plus serieux, le web n'a pas ete concu pour le monde de l'embarque, tu le remarques assez facilement sur tous les navigateurs web Android. Aucun ne va etre capable de mettre tes pages web en standby et ils sont oblige de les recharger completement. C'est juste un exemple. Il y en a d'autre et tu en trouveras par toi meme.
Le plus gros probleme du Web et surtout dans les dernieres annees et d'avoir de plus en plus pris la direction du "baremetal" en exposant des API de rendu direct. Cela impose de mettre toute la logique du rendu dans le JS et non dans le C. En prenant cette direction, ils ont certe plus de souplesse et ca evite de definir une API d'un toolkit de haut niveau (qui serait a mon avis impossible a faire standardise). Par contre, maintenant, cela impose une enorme logique en JS avec tous les problemes de performance que cela pose. Et dans ce genre de morceau de code, le controle de la memoire est absolument crucial.
C'est en fait le point le plus problematique et que les gens ne saississent pas facilement. Certe la quantite de memoire augmente exponentiellement, vive Moore. Par contre sa latence et sa consomation ne suivent pas du tout cette courbe. Pour faire simple, plus tu utilises de memoire plus tu vas devoir eviter les acces aleatoires (difficile quand tu es a faire du JS) et aussi plus tu utilises de memoire plus tu utilises de batterie. Tu peux compter un rapport 10 entre chaque niveau de la hierarchie memoire aussi bien pour la latence que pour la consomation. Enfin, si jamais tu atteinds la bande passante memoire limite de ta machine, ton CPU va attendre et consommer plus que si il pouvait juste dormir.
Devine quoi, faire un rendu graphique a l'ecran tombe exactement dans ces taches qui sont aux limites de la bande passante memoire et pour lequel tout cela compte terriblement.
Accessoirement pour proposer une alternative, c'est simple tu prends un toolkit graphique natif et tu mets du JS dessus. Tu eviteras tous ces problemes. KDE, Enlightenment et je crois aussi GNOME, on ca en stock.
Et sinon qui je suis pour juger, je suis un developpeur du projet Enlightenment et j'ai une petite idee de comment ca marche le monde de l'embarque et le rendu de graphisme optimise.
[^] # Re: Beurk
Posté par cedric . En réponse au journal Les vieux cons et le progrès…. Évalué à 4.
Ok, oublions le cote tablette. Je cuisine pas mal et j'ai beaucoup de livre de cuisine. Ils me servent d'inspiration et me donnent des idees. Une fois que j'ai une idee, je vais cherche des recettes sur le meme sujet. J'en arrive a avoir un ensemble de recette qui sont suppose donner le meme resultat. Je peux alors comprendre quel est probablement la recette qui aura le meilleur resultat. Au final, je vais l'ecrire pour la memoriser et pouvoir la reproduire.
Le livre est une bonne source de navigation aleatoire (les photos comptent enormement), mais loin d'etre complet et la navigation est catastrophique. En plus, il faut rechercher dans plusieurs livres pour avoir les reponses. Le net par contre, c'est mauvais pour decouvrir des recettes au hazard, par contre la recherche et l'analyse croise sont nettement plus facile.
Par contre, je te rejoind sur les tablettes. Elles sont just inadapte pour un usage en cuisine. Il faut un affichage tete haute (meme le bouquin, c'est chiant ca prend de la place, une feuille avec un aimant c'est nettement plus pratique), ensuite si on veut pouvoir naviguer dans l'interface il faut soit de la reconnaissance vocale soit de la reconnaissance de geste, mais pas d'interface tactile.
Par contre Internet est une veritable source de recette et je me devais d'en prendre la defense juste pour remercier toutes les personnes qui prennent le temps de contribuer leurs recettes. D'ailleur en quoi une contribution a ces sites est differences en qualite aux contributions a Wikipedia ou au logiciel libre ?
[^] # Re: Le web comme machine virtuelle ...
Posté par cedric . En réponse au journal Les vieux cons et le progrès…. Évalué à 8.
Il y a quand meme des differences majeurs dans le language qui rendent juste impossible d'avoir la meme simplicite pour la compilation et si une tache est plus complique, elle prend plus de temps et reste forcement plus lent. Surtout que la compilation/optimisation, ce n'est pas une tache simple a la base…
Et ton interface web, elle tourne dans quoi ? Une application native :-D Tu peux faire logiquement plus en natif que avec du web. L'inverse etant faux !
Pourtant Android, c'est du Java, c'est portable, ca marche partout ! Il y a dix ans, on me disait que ca serait vrai avec le Java… On avait les meme remarque, ca sert plus a rien de faire du natif, le Java resoud tous les problemes et il est plus rapide que le C… On m'a deja servi cette histoire, je ne vois pas ce qu'il y a de fondamentalement differement entre le monde Web et le monde Java. Quoique, les standards Web sont bien pire en terme de design que Java en fait. C'est 20 ans d'histoire et de hack sur une technologie qui n'a pas ete prevu pour ca, mais alors pas du tout !
[^] # Re: Et pour en remettre une couche
Posté par cedric . En réponse au journal Systemd: tuons les mythes. Évalué à 4.
Il doit preferrer la couleur rouge a la couleur verte !
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 3.
On parlait uniquement du cas software ici, donc on est d'accord :-)
On n'a clairement pas le meme laptop :-) Le mien tourne a 7W quand je code avec le compositeur software de E17 et Terminology, ca monte a 9W avec le compositeur GL. Mais il n'utilise pas l'extention de partial swap de Intel, peut etre qu'en l'implementant cela changerait la donne. Le compositeur sw va faire une copie que des zones qui ont change, alors qu'en OpenGL, tu es oblige de tout redessiner a l'ecran (Donc tu fais plus de boulot et tu utilises plus de hard). Pour ce qui est des copies de buffer, elles sont inherente a X et on ne peut s'en passer que avec une extention te permettant de controller directement les buffers et la mise a jour partiel. Malheureusement, je n'ai pas ce genre de fonctionnalite sur mon laptop, uniquement sur du SoC ARM et je ne peux alors que te donner des chiffres de Android vs X.
Tu as utilise quoi comme compositeur sw, car a part E17, je n'en connais aucun autre ? Et non, llvmpipe n'est pas une reponse valable pour moi. C'est une solution completement inadapte pour faire un compositeur avec un minimum de performance. C'est bien pour tester une stack GL, mais pas pour autre chose.
Je connais xdamage, merci :-) Et je pense que j'ai une petite idee de comment les flux passes entre X et les applications. Maintenant, j'ai clairement une experience plutot oriente SoC, donc avec des optimisations non disponible pour les GPU discrets.
Alors dans la vraie vie, les cartes a base de Radeon ont en general un driver bugge jusqu'a la moelle par exemple. C'est une des raisons pour lesquels avant de debugger le moindre bug report lie au compositeur dans Enlightenment, on demande sur quel carte graphique le probleme se pose. Pour l'histoire, fut un temps, le compositing ne pouvait marcher avec les drivers officiels de ATI que lorsque le process s'appele compiz… Et depuis, la situation ne s'est pas franchement ameliore chez eux. Chez NVidia, on n'a pas eu de probleme rapporte depuis quelques annees maintenant, mais leur driver genere des memcpy inutiles supplementaire qui font tourner le CPU pour rien lors de l'upload de texture entre autre chose (Je n'ai aucun retour d'utilisateur de Nouveau, ca veut dire que ca doit marcher :-)). Et chez Intel, ca semble etre bon avec les derniers drivers (Il y avait des dead lock en sorti de blank screen avant). Donc sauf a etre sur une Arch ou Gentoo, a peu pres personne n'a un driver correct.
Participant au developpement d'un compositeur, celui d'Enlightenment, j'ai une petite experience de l'etat du parc de driver posant probleme sur Linux. C'est sur, je ne vois que les gens qui viennent se plaindre ! Mais la situation est globalement mauvaise du cote des drivers Linux, c'est bien pour ca qu'il est succidaire de s'appuyer uniquement sur un compositeur hardware.
Il va falloir que je me remette a jour sur Wayland, mais ma comprehension du truc, c'est que l'application controle les buffers et qu'elle peut faire du double buffer en utilisant une combinaison de wl_surface_attach, wl_surface_damage et wl_surface_commit. Ce qui devient un chemin sans copie sur SoC, et se resoud par un DMA vers le GPU cote serveur Wayland sur un GPU discret. Mais ca, c'est dans mes souvenirs, ca fait bien un an que je n'ai pas regarde. Ca serait domage que ce ne soit plus le cas.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 3.
Vu que tu travailles plutot avec des GPU discret, la copie dont je parle se fait a coup de DMA dans ce cas la et est effectivement impossible a eviter sur ces GPU.
Hum, en fait, je n'ai jamais regarde en detail les i7 et i5 avec GPU integre, mais de ce que j'ai compris sur leur SoC, tu partage le meme controleur memoire. Certe tu dois negocier avec le GPU pour mapper la memoire dans l'adresse space du CPU. Mais cela devient directement accessible et ne genere pas de copie quand tu "unmap" ta memoire pour la rendre de nouveau utilisable par le GPU. Tu peux donc avoir ton rendu software qui va cycler sur un certain nombre de buffer directement utilisable par le GPU. Je n'ai pas travaille assez longtemps sur SoC Intel pour etre sur du comportement, mais sur SoC Qualcom et Samsung, tu as clairement ce comportement. Je soupsonne que c'est le cas pour toutes les SoC qui supporte Android.
C'est clairement sous optimal avec un GPU discret, donc il faut forcement garde le chemin avec xshm pour ce cas la. Pour les GPU a memoire partage, tu gagnes une copie memoire, ce qui a un impact direct sur les performances et se repercute principalement sur la consomation de la batterie (Le hard moderne tenant facilement les 60fps, c'est surtout la batterie qui montre les soucis de performance). Ce qui est logique, car toute operation que tu ne fais pas, ne consome pas de batterie :-) D'un point de vue difference, une stack X qui fait du xshm vs Android consomme plus de batterie aux environs de 30% (Mais ce chiffre dependra de ce que tu benchmark bienentendu).
Parce que la majorite des drivers OpenGL ne sont pas capable de tenir un mois sans cracher en faisant du compositing ? Je n'ai besoin de basculer mon compositeur en OpenGL que lorsque je fais du multiscreen. Et j'economise aussi de la batterie a reste en soft quand je code, car au lieu de redessiner tout l'ecran, il ne met a jour qu'un tout petit coin. Mais vu que je fais souvent de l'OpenGL, c'est pas mal de pouvoir quand meme avoir ce cas qui marche… Et ca, c'est sur un desktop, sur une tablette ou un telephone, le cas se presente encore plus frequement (consomation eleve de memoire du au context OpenGL, switch de context entre le compositeur et l'appli qui n'est pas forcement un moment joyeux, …).
Sinon de nos jours, c'est les GPU discrets qui sont en "voit" de disparition face au GPU a memoire integre. Comparer le nombre de Linux dans un cas et dans l'autre est d'ailleur assez vite fait ! Plus d'un million sont active par jour avec une memoire partage… Et Wayland ainsi que le futur de Linux se trouve dans ce domaine la, donc il faut que ce cas soit optimisable.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 2.
Ce qui reste un cas particulier avec un seul rectangle :-) Tu me l'accordera, mais tu passes quand meme pas mal de temps devant ton ecran a regarder des applications statiques ou seule un petit curseur de 10 par 20 pixels clignotes. Si tu travailles sur ton laptop avec un compositing et des applications incapable de faire du partial update, tu vas y perdre une bonne partie de ta batterie a rien faire d'autre que de redessiner la meme chose a l'ecran. C'est d'ailleur une des optimisations d'Android, les applis sont en rendu direct la plus part du temps et font au tant que possible du partial update. La difference de consommation avec un X/Toolkit classique qui ne fait pas attention est de l'ordre de 50% de conso supplementaire sur des simples zone de texte qui clignote par exemple.
Je me suis peut etre pas exprime assez clairement. Mais il est completement possible d'implementer au niveau des compositeurs X, l'equivalent de ce que fait le protocol Wayland. C'est d'ailleur surement le chemin que vont suivre la plus part des desktops linux en implementant Wayland en parallele de leur compositeur X. Bien entendu, ca, c'est en oubliant le probleme de securite. Mais l'interet sera d'avoir une adoption plus rapide de Wayland et un test grandeur nature des limites du protocol aussi. Il y a encore quelques trucs necessaire pour faire un desktop Linux complet avec Wayland et tant que ce ne sera pas la, ca avancera doucement.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 3.
Xshm te donne une position et une taille, donc il y a bien une copie a ce moment la. Si tu as un GPU discret (discrete GPU ?), c'est effectivement une bonne chose de ne pas reuploader toute ta fenetre et de t'appuyer sur un DMA pour faire la copie. Par contre, si tu es sur la meme memoire, cas des SoC et de Intel, il vaudrait mieux completement eviter le DMA en accedant directement a la surface video. La plupart des SoC et Intel supporte de faire les operations depuis une surface non tile/compresse avec une faible perte de performance qui dans la pratique devient un gain du fait de l'absence de copie et de cas de rendu direct (pas de compositing, car fenetre au dessus ou plein ecran).
Par contre, ton point sur Wayland m'ennuie. Je sais que la partie rendu soft n'est pas vraiment au point (quid d'une appli OpenGL avec un compositing software par exemple). Mais bon, dans le pire des cas, tu dois pouvoir utiliser l'api EGL en maintenant le rendu en soft pour obtenir le meme resultat, non ?
Les GPU Intel et la plupart des SoC tombe pourtant dans cette categorie. Apres c'est vrai que pour NVidia et ATI, ce n'est pas le cas, mais c'est pas la majeur partie du parc. C'est bien pour ca que j'avais fait une petite liste de condition ;-)
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 5.
Si les Enlightenment Foundation Library font tout a fait ca ! L'inconvenient est que le code de redimensionnement des fenetres X avec OpenGL est particulierement lent (on peut limite compter en seconde). Cela limite donc son utilisation a des machines types telephone, tablette ou tv. La ou l'utilisateur ne peut pas jouer avec la taille de la fenetre.
[^] # Re: Heu et ca ameliorera quoi chez qui ?
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 0.
En general avec de l'ATI, tu pars quand meme avec un bon handicap… Tu peux toujours tenter des environnements plus leger, mais il ne faut pas croire au miracle.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 4.
Il reste que le protocol X (Xlib ou Xcb) est toujours serialise dans une socket. Ok, il y a moins de requete dedans, si on n'utilise pas Xrender, mais ca n'empeche que le cout de la serialisation dans un socket est la. Une amelioration simple serait d'utiliser un buffer shm pour communiquer avec X et de n'envoyer dans la socket que l'index ou commence dans le buffer shm de la serie de commande X. Cela serait plus efficace a mon avis pour les communications locales. Je me demande d'ailleur, comment est implementer cette partie la du protocol Wayland, je crois que ca passe tout dans la socket.
Ca depend. Si on fait du rendu soft, que le GPU utilise la meme memoire que le CPU et que le backend soft comprend le format du GPU alors oui. Sinon la vie est plus complique.
[^] # Re: Compiz ne migrera pas vers Wayland
Posté par cedric . En réponse à la dépêche Petites brèves autour de Wayland. Évalué à 6.
La grosse amelioration de Wayland, c'est surtout le control du buffer video par l'application. Avec X, meme lorsqu'on evite d'utiliser Xrender pour le rendu, on est encore force d'uploader des buffers de pixels via xshm. Cela genere des memcpy inutile. Avec Wayland, l'application/le toolkit utilise deux buffers video et fait automatiquement les delta sur deux frames. Cela evite le memcpy inutile.
Mais techniquement, il n'y a rien la dedans qui ne serait pas impossible a faire avec X. En fait pour obtenir les meme perf, il suffirait de pas grand chose dans DRI (peut etre dans la version 3). Support de la mise a jour partiel et recuperation des buffers d'une fenetre. Du cote compositeur, il n'y a pas de changement a faire. Ce genre de fonctionalite serait aussi tres utile dans OpenGL, Intel a une extention pour ca, mais ca marche moyen.
Donc on peut encore corriger X pour etre aussi efficace que Wayland… Le seul truc qu'on ne peut pas, c'est le rendre sur. Ca, c'est la seule chose impossible sans changement d'architecture et c'est vraiment la ou Wayland vaut le cout.
[^] # Re: sans intérêt
Posté par cedric . En réponse au journal Ubuntu phone OS. Évalué à 2.
C'est sur Bill et ses 640K, il pouvait pas aller bien loin… Non, tu es serieux avec tes 25k ? C'est absolument enorme comme taille ! Deja 2K, c'est considere comme etant un peu obese, mais la juste 10 fois plus et ca ne te fais pas sourciller…
Et si tu testais avec une application native… Non, parce que le souci, c'est le standard qui rend difficile toutes optimisations. Un claws-mail vs GMail sur Firefox ou Chromium, ca donne quoi chez toi ? Chez moi, c'est clairement a l'avantage de claws-mail, et pourtant c'est pas l'archetype du machin optimise et ils n'ont pas les ressources Google ou Mozilla pour optimiser tout ca.
Le probleme n'est pas Firefox ou Chrome, mais le standard lui meme qui pousse a la consomation de ressource et dont on peut difficilement voir pas du tout, faire le tour.
[^] # Re: sans intérêt
Posté par cedric . En réponse au journal Ubuntu phone OS. Évalué à 3.
Si mon gmail prend plus de memoire que mon claws-mail, ca veut dire quelque chose !
J'ai suffisament d'experience sur comment optimiser un pipeline de rendu graphique et sur le materiel disponible pour les constructeurs de telephone pour estimer pouvoir prendre ce parie. J'ai une idee assez precise de ce qu'on peut avoir et pour quel prix. Il y aura forcement draw back a leur choix.
Encore heureux que le rendu graphique ne soit pas en JS ! Mais si tu as un jour code un pipeline graphique, tu saurais que la plus grande difficulte est dans le scene graph qui est en charge de gerer les requetes au code de rendu direct. Ce code la est massivement code en JS (exemple le petit lien plus haut sur facebook…). Et le JIT ne t'aidera pas beaucoup par rapport a du natif, car tu as un certain nombre d'optimisation impossible du fait de l'impossibilite de manipuler la memoire directement. Cela bien entendu en partant du principe que ton JIT et ton toolkit JS se comprenne bien…
Ce n'est pas un domaine trivial que de reussir a optimiser ton code non type sans gestion de la memoire pour qu'il soit proche en terme de vitesse de ce qu'on fait en natif de maniere naive. Et tout comme le Java pendant la derniere decennie, le JS, dont le JIT est fait au runtime, sera forcement toujours plus lent que du code natif au petit oignon. Et oui, les toolkits natifs font de gros effort sur ces morceaux de code.
[^] # Re: J'ai le même
Posté par cedric . En réponse au journal Le logiciel qui prédit les délits. Évalué à 4.
Tu sais que plus de 60% des transactions a la bourse de New York sont le fruit d'operation completement automatique et sans aucune intervention humaine autre que la programation du dit algorithm ? On appel ca le High Frequency Trading… Ah oui, on est en 2013 apperement !
[^] # Re: sans intérêt
Posté par cedric . En réponse au journal Ubuntu phone OS. Évalué à 5.
Desole, 17.0.
Peut etre qu'on n'a pas la meme definition de econome en fait. Pour 4 tab ouvert, j'ai 240Mo qui disparaisse…
C'est deja un bon debut que ca fasse du 60 fps tout le temps. On est en 2013 et on a des SoC couillu meme dans le low cost de nos jours. Par contre, ce qu'on remarque moins directement c'est la consomation de la batterie. Je te propose un jeu. Implemente un simple test qui scroll de haut en bas en boucle en affichant du texte et des images. Fait le meme rendu sur Android. Fait ensorte que chacun tienne ses 60FPS. Prend maintenant ton wattmetre et mesure. Je suis pret a parier que Firefox OS est au dessus en conso ou au mieux au meme niveau.
A titre d'indication, avec les EFL et un bon driver X, on est a une conso 2 fois moindre que Android (ca implique que tu peux prendre un CPU/GPU deux fois moins puissant ou que ton telephone aura une plus grande autonomie). Je pense que Qt doit se situer entre les deux etant donnee que leur scenegraph n'a pas eu autant le temps de s'optimiser.
La raison pour laquelle je pense que Firefox OS va avoir des problemes de performance, c'est qu'il deporte la resolution du souci plus haut dans la stack. Il faut utiliser un toolkit JavaScript qui soit malin et optimiser pour que son appli ne rame pas. Ce qui veut dire que dans le meilleur des cas, le boulot est fait en JS pour le chemin critique. Hors en JS, tout comme en Java, tu n'as aucun controle sur l'allocation memoire et tu ne peux pas maitriser ton cycle memoire. Or en terme de performance, a partir du moment ou tu as un scenegraph (avec OpenGL ou software), la maniere et la quantite de memoire que tu manipules devient critique et a un impact direct sur le resultat. Bien entendu, ca c'est quand tout le monde code super bien en HTML/JS et utilise le bon toolkit bien optimise pour que tout se passe bien…
[^] # Re: .
Posté par cedric . En réponse au journal Ubuntu phone OS. Évalué à 5.
Si ton moteur graphique est ecrit en C/C++, tu as des le depart un avantage majeur sur Google. Le principal probleme, c'est que pour avoir des perfs, il te faut maitriser ton allocation memoire au maximum et ca, en faisant ton moteur dans une VM, tu l'as perdu !
Par contre, le vrai probleme de Ubuntu, c'est qu'ils sont tres mauvais sur les quantites de RAM dont ils ont besoin pour fonctionner. J'espere pour eux qu'ils ont un plan pour resoudre ce probleme. Le probleme etait dramatique sur Nexus 7/Ubuntu, il ne restait plus que 300M pour les applications sur 1Go.
Je n'ai pas plus de mesure sur Qt et Ubuntu, mais faire un toolkit qui consomme moins de memoire, CPU/GPU et batterie que Android… c'est faisable par une petite equipe. Les EFL consomment a performance graphique equivalente 50% de moins en batterie. Elles n'ont pas besoin de GPU et consomme aussi moins de memoire. Partir d'un bon design, evite d'avoir besoin d'une armee titanesque pour resoudre le probleme ! ;-) Et d'un point de vue design, QML/SceneGraph est sur les traces de ceux que font les EFL, donc ils doivent potentiellement avoir le meme avantage a terme.