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…
[^] # 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…