Chrome : Ignition doit réduire la consommation de mémoire vive autour de JavaScript

Chrome : Ignition doit réduire la consommation de mémoire vive autour de JavaScript

Bon, de 5 % dans un premier temps

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

30/08/2016 3 minutes
71

Chrome : Ignition doit réduire la consommation de mémoire vive autour de JavaScript

Durant la conférence BlinkOn, Google a présenté un nouvel interpréteur JavaScript pour Chrome. Baptisé Ignition, il aura dans un premier temps la mission de réduire la consommation de mémoire vive, particulièrement sur les appareils mobiles.

Le JavaScript, comme tout langage de script, est interprété ou compilé. Contrairement à un exécutable binaire qui peut être exécuté directement, il doit d’abord être traduit en langage machine. C’est le travail du compilateur JavaScript à la volée (just-in-time), qui permet de générer de l’assembleur avant de l’envoyer pour traitement au processeur.

Dans la machine virtuelle JavaScript V8 de Chrome, ce compilateur est basique : il doit avant tout générer un code machine aussi rapidement que possible. Cette phase, dont la durée doit être minimale, a l’inconvénient de pouvoir consommer une grande quantité de mémoire vive, même quand le code n’est exécuté qu’une fois. Ledit code circule en fait dans un pipeline d’exécution, qui permet en fonction de ce qui y est détecté de passer le relai à deux autres compilateurs, optimisés ceux-là : Crankshaft et TurboFan.

Ignition simplifie le pipeline d'exécution

Arrive Ignition. Il s’agit d’un nouvel interpréteur de JavaScript, qui peut se substituer au compilateur de base en début de pipeline de V8. L’intérêt d’Ignition est double selon Google : simplifier la chaine d’exécution et procéder à une compilation moins gourmande en mémoire vive. Pour ce faire, Ignition applique une recette connue : le script compilé est transformé en bytecode, un code « prémaché » dont le poids ne représente plus que la moitié, voire le quart de celui d’un code compilé basique.

google chrome ignition

Le bytecode passe ensuite à la moulinette d’un autre interpréteur, conçu pour cette opération. Le résultat dispose des optimisations spécifiques à la plateforme matérielle détectée. Google n’a pas réinventé la roue : l’éditeur a tout simplement réutilisé les instructions macro-assembleur de TurboFan pour concevoir Ignition. Il fournit donc au compilateur final un code équipé de tous les « marqueurs » nécessaires pour une architecture donnée.

Uniquement pour Android sur de petits appareils pour l'instant

Ignition devra cependant attendre pour révéler son plein potentiel. Il ne sera actif dans un premier temps que dans la version Android de Chrome, et uniquement pour des appareils qui disposent de 512 Mo de mémoire vive ou moins. D’après les tests réalisés par Google, la consommation en mémoire diminue d’environ 5 % sur chaque onglet.

Ross McIlroy, qui en gère le développement, indique cependant qu’Ignition offre d’autres possibilités, notamment de pouvoir « prendre de meilleures décisions » sur le bon moment pour exécuter et optimiser le code, grâce à la simplification du pipeline. Ceux qui souhaitent en savoir davantage sur Ignition pourront lire la présentation réalisée par Google.

71

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Ignition simplifie le pipeline d'exécution

Uniquement pour Android sur de petits appareils pour l'instant

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (71)


J’ai rien compris, mais ça a l’air vachement chiadé <img data-src=" />


5% par onglet ! Wahou ! <img data-src=" />&nbsp;



Pas mal du tout.&nbsp;<img data-src=" />


Quid de la conso CPU?








_Quentin_ a écrit :



J’ai rien compris, mais ça a l’air vachement chiadé <img data-src=" />





En gros, ils proposent que les développeurs fabriquent à partir de leur sources Javascript un fichier contenant du bytecode (avec l’extension .class) qu’ils compressent dans un fichier zip auquel ils donnent l’extension .jar



<img data-src=" />

&nbsp;<img data-src=" /><img data-src=" />



&nbsp;<img data-src=" /><img data-src=" /><img data-src=" />



En attente de la disparition de Javascript.


C’est bien, tu m’as fait rire. Maintenant réveil toi néo.


Y a pas qu’avec JS que la consommation de mémoire vive doit être réduite… Chrome est un aspirateur à mémoire vive. Ceci dit en passant, Firefox fait pas mieux.


var me = “lol”;



Le JavaScript à un avenir radieux.


On est pas dans la m…e <img data-src=" />


La plupart des pages web n’ont pas besoin réellement de Javascript. Je pense qu’il manque quelque chose pour pouvoir dynamiser sans Javascript, par exemple définir une zone comme étant un flux, et qui est mis à jour automatiquement, pour remplacer une partie d’ajax. J’aimerais vraiment voir le Javascript réduit à un bac à sable/plugin. Mais disons que je suis fanatique, avec NoScript.

Et le HTML/CSS pourraît être remplacé par des formes de contenu standardisées (mais qui définirait ces standards ?) - on pourrait plus facilement suivre localement notre thème GTK+/Qt/autre sans utiliser des extensions qui forcent plus ou moins un thème en CSS (faire du cas par cas est impossible). Aujourd’hui le web blanc/clair fait mal aux yeux, au sens propre.

En fait, il faudrait repenser un nouveau format de données, qui sépare design et contenu. Je vois tout de suite des gens m’entendre dire qu’il faut retourner à la préhistoire, mais évidemment que je ne veux pas que le web se referme. J’ai pas de prototype à montrer, et je vois un problème entre liberté et standardisation dans mon idée pour l’instant.


C’est pas si mal que ça l’ecmascript 6








Exagone313 a écrit :



il faudrait repenser un nouveau format de données, qui sépare design et contenu.





Allez, soyons fous …





Je propose un couple de deux technos complémentaires, l’une pour le contenu sous forme structurée ; l’autre pour la représentation graphique.



Appelons les HTML pour le premier et CSS pour le second.

&nbsp;





&nbsp;&nbsp;



Séparé design et contenu, comme du CSS et du HTML “grosso modo”.

Du web avec GTK+/Qt/autre truc bien lourd, c’est pas non plus l’idée du siècle.

Le web d’aujourd’hui leger et sans interface lourde me plait plus que la tres grande majorité des applications pleine de chrome souvent dégueulasse car faite par des gens qui n’ont aucune reflexion sur les interfaces pratique et jolies (c’est possible, il suffit de voir ce qui se fait sur OSX).


Il est vrai… NodeJS est un “client léger” et ça consommation de ram est 10x inférieur à chromium.


Oracle devrait porter plainte contre Google pour plagia de la JVM <img data-src=" />








Liara T’soni a écrit :



Il est vrai… NodeJS est un “client léger” et ça consommation de ram est 10x inférieur à chromium.





Il me semble avoir lu quelque part que même si Chrome et NodeJS partagent le même moteur JS, il y avait au final une assez grande différence de la façon dont est traitée le code JS, du fait d’une ‘configuration’ des paramètres du moteur (d’optimisation notamment) assez différente.



&nbsp;J’ai pas vérifié par moi-même, mais ça me paraîtrait pas totalement déconnant: une appli NodeJS on s’en fout un peu qu’elle mette quelques millisecondes de plus à se lancer, ou qu’elle utilise quelques Mo de RAM temporairement utilisés pour compiler agressivement tout le code dès le départ. Par contre, l’important c’est qu’une fois l’appli lancée, il faut que ça dépote ensuite.

A l’inverse, le temps de chargement initial d’une page dans un browser, et sa conso en RAM sont des éléments importants (surtout quand on a 50 pages ouvertes en même temps)&nbsp; ; sans doute bien plus important que quelques % de perfs en plus ou en moins dans l’exécution du code JS proprement dit.

&nbsp;

Enfin, même si les deux parlent du JS, ils ont des traitements typiques plutôt distincts: en général, le code d’une page sert essentiellement à manipuler du DOM ; le code d’une appli JS est beaucoup plus orienté I/O et calculs.

&nbsp;



mince je pourait pas utiliser sur mon thl 4000&nbsp;<img data-src=" />


J’aime ton idée








brazomyna a écrit :



Allez, soyons fous …





Je propose un couple de deux technos complémentaires, l’une pour le contenu sous forme structurée ; l’autre pour la représentation graphique.



Appelons les HTML pour le premier et CSS pour le second.





mais tu es un grand malade toi !! c’est complètement insensé cette approche <img data-src=" />



«Java is to JavaScript as car is to carpet»


Y a pas de quoi mettre le feu aux poudres.



–&gt; [] <img data-src=" />


So 2015. On en est à ecmascript 7 depuis juin. <img data-src=" />


Firefox fait largement mieux et se bonifie avec le temps en conso mémoire, malgré le bad buzz qui lui colle à la peau. Ici, 26 onglets, 433 Mo en x86.

[edit:]En chargeant pour de vrai les 26 onglets, c’est 802 Mo, ce qui reste honorable.


ouais du xml et du xsl quoi








33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



En gros, ils proposent que les développeurs fabriquent à partir de leur sources Javascript un fichier contenant du bytecode (avec l’extension .class) qu’ils compressent dans un fichier zip auquel ils donnent l’extension .jar



<img data-src=" />

&nbsp;<img data-src=" /><img data-src=" />



&nbsp;<img data-src=" /><img data-src=" /><img data-src=" />





Mais non, en fait maintenant qu’on a éliminé le flash dans les pages web pour le remplacer par du javascript, on s’aperçoit que finalement c’est pas mieux, et même souvent pire, du coup on refais du flash sauce javascript…



Moi j’aimerais bien du QML (Qt Quick) plutôt que le html.


t’as vu les 5 trolls ? <img data-src=" />








damaki a écrit :



Firefox fait largement mieux et se bonifie avec le temps en conso mémoire, malgré le bad buzz qui lui colle à la peau. Ici, 26 onglets, 433 Mo en x86.

[edit:]En chargeant pour de vrai les 26 onglets, c’est 802 Mo, ce qui reste honorable.





Faut arrêter un peu avec ça, on a complètement déchargé les serveurs au profit des clients. 26 pages affichés &nbsp;pour 802 Mo c’est énorme : une consommation de 30Mo par page pour du texte des images…



Bond, de 5% ….. c’est bon aussi ?








wanou2 a écrit :



une consommation de 30Mo par page pour du texte des images…





Pour moi c’est au contraire que dalle.



Tu prends la présente page de NextInpact, tu la sauvegardes avec l’ensemble des fichiers de ressources attachés, tu récupères déjà plus de 3Mo d’images en tout genre, toutes compressées au maximum.

Tu prends rien que ces images, tu les mets en mémoire dans un format non compressé, tu as facile un facteur 5 ou 10 de mémoire

&nbsp;

Tu as même pas commencé à allouer un peu de mémoire pour le JS à exécuter ; pas encore de RAM pour mettre un minimum quelques rendus partiels de la page en cache, rien sur toutes les métadonnées des différents éléments, etc… et tu as déjà bouffé tes 30Mo.

&nbsp;

Tu voudrais quoi ? De la magie ?

&nbsp;



&nbsp;Chrome sur un phone avec 512mo il y a du boulot…



T’ouvre n’importe quel site ça balance un low memory<img data-src=" />








brazomyna a écrit :



Pour moi c’est au contraire que dalle.



Tu prends la présente page de NextInpact, tu la sauvegardes avec l’ensemble des fichiers de ressources attachés, tu récupères déjà plus de 3Mo d’images en tout genre, toutes compressées au maximum.

Tu prends rien que ces images, tu les mets en mémoire dans un format non compressé, tu as facile un facteur 5 ou 10 de mémoire

&nbsp;

Tu as même pas commencé à allouer un peu de mémoire pour le JS à exécuter ; pas encore de RAM pour mettre un minimum quelques rendus partiels de la page en cache, rien sur toutes les métadonnées des différents éléments, etc… et tu as déjà bouffé tes 30Mo.

&nbsp;

Tu voudrais quoi ? De la magie ?

&nbsp;





Mouais… il y a 10 ans les machines avait des puissances et surtout des quantités de mémoire largement inférieur à aujourd’hui. Les sites n’était pas beaucoup moins beau qu’actuellement et les consommations mémoires très inférieur. Je n’y connais rien mais j’ai quand même l’impression d’un gâchis de ressource dans le domaine plutôt qu’autre chose !



Mais bon tu as sans doute raison, il est normal de bouffer plus de 140 Mo pour afficher une page (le navigateur (chromium) + cette page sur ma machine…)









psn00ps a écrit :



t’as vu les 5 trolls ? <img data-src=" />





Six, en fait&nbsp;<img data-src=" />









wanou2 a écrit :



Mouais… il y a 10 ans les machines avait des puissances et surtout des quantités de mémoire largement inférieur à aujourd’hui. Les sites n’était pas beaucoup moins beau qu’actuellement et les consommations mémoires très inférieur. Je n’y connais rien mais j’ai quand même l’impression d’un gâchis de ressource dans le domaine plutôt qu’autre chose !





Il y a 10 ans, une page web c’était des images 10 fois moins grosses, des résolutions 4 fois inférieures, etc…

Non, c’était “pas exactement” la même chose que maintenant.







wanou2 a écrit :



&nbsp; plus de 140 Mo pour afficher une page (le navigateur (chromium) + cette page sur ma machine…)





Non, mais tu devrais aussi ajouter la mémoire prise par l’OS aussi, pour avoir une analyse encore plus fine.



Bordel, 1Go pour afficher une page web <img data-src=" />

&nbsp;









brazomyna a écrit :



Il y a 10 ans, une page web c’était des images 10 fois moins grosses, des résolutions 4 fois inférieures, etc…

Non, c’était “pas exactement” la même chose que maintenant.





Le problème c’est que maintenant mon ordi a une résolution de 1366768 alors qu’il y a 10 ans mon ordi avait une résolution de 1280800 alors moi je vois la même chose&nbsp;<img data-src=" />









brazomyna a écrit :



Bordel, 1Go pour afficher une page web <img data-src=" />

&nbsp;





Sur 1006 Mo actuellement consommé 441 Mo sont consommés pour cette page web sur firefox <img data-src=" />









wanou2 a écrit :



Sur 1006 Mo actuellement consommé 441 Mo sont consommés pour cette page web sur firefox <img data-src=" />





le poids des mots, tout ça tout ça <img data-src=" />









WereWindle a écrit :



le poids des mots, tout ça tout ça <img data-src=" />





&nbsp;Tu savais que, une fois décompressée en mémoire, ton avatar pesait plus de 100ko dans ma ptite RAM ?

&nbsp;



IN-AD-MIS-SIBLE !!! <img data-src=" />









brazomyna a écrit :



Tu savais que, une fois décompressée en mémoire, ton avatar pesait plus de 100ko dans ma ptite RAM ?

 



IN-AD-MIS-SIBLE !!! <img data-src=" />



Le poids des mots de son avatar… <img data-src=" />



Tu confond beauté et ergonomie.&nbsp;

Oui il y a 10 ans les pages n’étaient pas tellement moins belles (enfin c’est très relatif). Une image peut être belle, ce n’est pas la question.&nbsp;

Aujourd’hui tu peux interagir avec la plupart des éléments d’une page, sans avoir un rafraîchissement.&nbsp;

Et comme tu le dis, la définition d’écran a été multiplié par 4, et le poids des images à plus ou moins suivit.&nbsp;

Il y a 10 ans, il n’y avait aucun plugin, aujourd’hui la plupart des visiteurs ont au moins 3 plugin accroché au navigateur, souvent plus.&nbsp;

Il y a 10 ans il n’y avait pas ou peu de trackers, aujourd’hui rare sont les sites qui en ont moins de 5.&nbsp;

Il y a 10 ans, la sécurité des navigateurs était nulle, aujourd’hui il y a des tas de mécanismes de sécurité, qui prennent forcément de la ram.&nbsp;

Il y a 10 ans, les navigateurs ne savaient lire que des pages web. Aujourd’hui ils sont capable d’ouvrir de nombreux types de documents.&nbsp;



Aujourd’hui les sites internet ont des interfaces aussi riche voir plus riche que la plupart des logiciels d’il y a 10 ans.&nbsp;

Pour ce que tu dis sur le fait de décharger les serveurs vers les clients, c’est un peu vrai. Mais ce que tu perds en ram, tu le gagnes en fluidité, car faire des aller-retours entre le client et le serveur rend l’expérience de navigation très désagréable.&nbsp;



Plusieurs sites proposent des versions sans javascripts (gmail par exemple), mais c’est très désagréable à utiliser. A coté de ça, le prix de la mémoire vive a beaucoup baissé. Donc je ne vois pas pour qu’elle raison il faudrait revenir à l’internet d’il y a 10 ans. &nbsp;








Patch a écrit :



Le poids des mots de son avatar… <img data-src=" />





Ok, va. Je valide. <img data-src=" />

&nbsp;









blackdream a écrit :



Plusieurs sites proposent des versions sans javascripts (gmail par exemple), mais c’est très désagréable à utiliser.





C’est cette version que j’utilise parce que je trouve la version “normale” trop lourde. En html, c’est hyper efficace (à mon goût), plus rapide à charger (je clique ça affiche dans la seconde), j’ai pas de machin chat contact qui s’affiche à chaque fois que je bouge ma souris, je ne clique pas par erreur sur un bouton parce qu’un truc s’est chargé entre temps, …



&nbsp;En fait… je suis un vieux con anti-progrès :‘(



Bah… ouai&nbsp;<img data-src=" />

La version allégée peut avoir de l’intérêt sur un vieille ordinateur, mais elle enlève des fonctionnalités sympa je trouve. Et puis j’ai pas l’impression que la version complète est si lourde que ça, mais bon les ordinateurs que j’utilise ont tous 4go ou plus. &nbsp;








blackdream a écrit :



Bah… ouai&nbsp;<img data-src=" />

La version allégée peut avoir de l’intérêt sur un vieille ordinateur, mais elle enlève des fonctionnalités sympa je trouve. Et puis j’ai pas l’impression que la version complète est si lourde que ça, mais bon les ordinateurs que j’utilise ont tous 4go ou plus. &nbsp;





Moi c’est un vieux celeron n2840 avec 2 Go de ram. Sous nunux ça passe sous win10 ça rame sévère !



Faut qu’on m’explique cette haine courante pour le JS, avant c’était PHP qui prenait le plus cher, il est en passe d’être détrôné <img data-src=" />


Bah si le navigateur fait le job et que j’ai plus à optimiser chaque bout de code ou d’image je m’en porterai pas plus mal /troll


Le 6 n’est même pas encore entierement supporté par tous les navigateurs. On a de quoi voir venir pour le 7…








CNek a écrit :



Faut qu’on m’explique cette haine courante pour le JS, avant c’était PHP qui prenait le plus cher, il est en passe d’être détrôné <img data-src=" />





Chez les développeurs c’est comme partout: tu auras toujours une proportion de gugus incapables de dépasser le raisonnement d’un enfant de 5 ans.



Pour ceux là, il faut obligatoirement qu’ils se définissent des ‘gentils’ langages, parfaits, idéaux et hégémoniques. Et puis des ‘méchants’ langages qui cumulent à eux seuls toutes les tares du monde. Entre les deux, point de salut.



C’est la seule façon qu’ils ont de se représenter les choses. Toute autre représentation un tant soit peu plus nuancée, pondérée et donc intrinsèquement plus complexe, dépasserait leurs capacités intellectuelles.



Et comme “ils osent tout et c’est même à ça qu’on les reconnait”, tu peux être sûr que ce sont eux en priorité qui vont se sentir obligés d’exprimer leur point de vue sur les espaces d’expression.



Pour moi, l’onglet Gmail est le processus n°1 en consommation mémoire, devant éclipse.

150 Mo rien que pour lui en début de journée !








flamaros a écrit :



Moi j’aimerais bien du QML (Qt Quick) plutôt que le html.





Pareil. Il y a tellement d’éléments dynamiques dans une page web qui pourraient être codées de façon déclarative sans avoir recours à du javascript. Et je ne parle pas du système de placement des éléments du html/css qui a été conçu pour représenter des documents et qui est inadapté à la conception d’UI.

&nbsp;

Si tu es intéressé, il y a des développeurs qui ont utilisés emscripten pour transformer le moteur qtquick en javascript:

démo qt quick dans un navigateur



C’est complètement expérimental, mais c’est quand même une belle prouesse d’avoir transpilé en javascript le moteur javascript de chrome utilisé par qtquick et le faire exécuter par le moteur javascript de chrome <img data-src=" />









megabigbug a écrit :



Pareil. Il y a tellement d’éléments dynamiques dans une page web qui pourraient être codées de façon déclarative sans avoir recours à du javascript.





Un peu comme le fait CSS3, quoi.

&nbsp;



Ou alors, peut-être, existe-t-il des gens qui constatent que le modèle objet de JavaScript - où chaque objet n’est qu’une collection de propriétés nommées - est bien adapté syntaxiquement à la représentation compacte d’un élément du DOM dans une expression (vu que c’est à ça qu’il était destiné), mais à-peu-près rien d’autre ?



Ou alors qu’il existe des gens qui s’émeuvent que ce langage, hégémonique dans les browsers car bien adapté à la manipulation du DOM, est poussé dans des applications où il est largement sorti de son domaine de compétences pour l’unique raison que “comme ça vous pouvez utiliser le langage que vous connaissez déjà” ?


Ah ouai quand même !&nbsp;

Chez moi c’est pas le premier : aucun processus chrome ne prend plus de 100mo de mémoire (j’ai 8 onglets d’ouvert, dont gmail).&nbsp;

Au dessus j’ai sql développeur, firefox (2 onglets dont une boite mail) et en tête de liste j’ai mon zend-eclipse à 400mo ! (13 projets, 4 fichiers ouverts).&nbsp;

&nbsp;








blackdream a écrit :



Ah ouai quand même ! 

Chez moi c’est pas le premier : aucun processus chrome ne prend plus de 100mo de mémoire (j’ai 8 onglets d’ouvert, dont gmail). 

Au dessus j’ai sql développeur, firefox (2 onglets dont une boite mail) et en tête de liste j’ai mon zend-eclipse à 400mo ! (13 projets, 4 fichiers ouverts).





C’est l’éternel problème : à chaque news, il y a des comparaisons de conso mémoire entre INpactiens, mais sans protocole précis. Tout dépend des pages ouvertes, de leur contenu, de la navigation effectuée, etc.

Pour être précis, il faudrait simplement un jour que quelqu’un fasse le même test avec les mêmes pages sur 2 navigateurs d’un même PC.



Natürlisch! ;)


Bah là c’était surtout pour comparer la conso de gmail, mais c’est vrai que même sur une seule page il y a plein d’autre choses qui peuvent influencer (plugins, os, version de chrome etc).&nbsp;


2 mots: left-pad :p (bon ok non seulement c’est du troll mais en plus c’est en NodeJS)



Sinon le problème vient en partie je pense de l’héritage que le langage doit supporter et qui peu paraître pas super propre (api de base bordélique dans certains cas, le fait de pas avoir les types de base classique genre Number etc etc).



Dans tous les cas j’attends les WebAssembly avec impatience <img data-src=" /> (ouai je sais, je peux toujours attendre)


Oui, mais Babel le supporte déjà dans une certaine mesure. Et vu que Babel est quasi obligatoire pour la compatibilité et les polyfills d’IE, autant y aller à fond et utiliser ES7.


J’ai commencé les hostilités et je m’en excuse. C’était juste à titre indicatif.

Et soit dit en passsant, pour Chrome, c’est pas évident de calculer son utilisation mémoire réelle à cause des process séparés et de la mémoire partagée.








damaki a écrit :



J’ai commencé les hostilités et je m’en excuse. C’était juste à titre indicatif.

Et soit dit en passsant, pour Chrome, c’est pas évident de calculer son utilisation mémoire réelle à cause des process séparés et de la mémoire partagée.





Y a pas de souci, ça reste très courtois :)









megabigbug a écrit :



Pareil. Il y a tellement d’éléments dynamiques dans une page web qui pourraient être codées de façon déclarative sans avoir recours à du javascript. Et je ne parle pas du système de placement des éléments du html/css qui a été conçu pour représenter des documents et qui est inadapté à la conception d’UI.



&nbsp;      

Si tu es intéressé, il y a des développeurs qui ont utilisés emscripten pour transformer le moteur qtquick en javascript:



démo qt quick dans un navigateur




C'est complètement expérimental, mais c'est quand même une belle prouesse d'avoir transpilé en javascript le moteur javascript de chrome utilisé par qtquick et le faire exécuter par le moteur javascript de chrome <img data-src=">







Oui je connais le port javascript de QtQuick , mais idéale serait que le scene graph QML soit directement intégré dans les navigateurs, c’est tellement plus performant pour le rendu que le html/css qui est extrêmement complexe pour le positionnement,… D’ailleurs pendant des années les différents moteurs de rendu html avaient des présentations différentes des mêmes pages.

En QtQuick au moins c’est l’utilisateur qui défini les règles de rendu, le moteur ne s’occupant que d’appliquer des simples transformations sur une hiérarchie d’éléments.



Et le fait que le QML soit déjà un dérivé du JS faciliterait l’adoption.



J’arrive pas à me mettre au html car c’est l’enfer quand on débute de régler la mise en page surtout si on veux en plus gérer le resize qui s’adapte à l’écran.



Ca doit dependre de ta formation.



Je trouve le couple HTML + CSS tres simple à utiliser.

Et honnêtement, faire du style en JS, c’est à vomir… du moins pour le peu que j’ai essayé avec react + jsx.








brazomyna a écrit :



Un peu comme le fait CSS3, quoi.

&nbsp;





Non, le CSS3 ne permet pas de faire ce que fait QML.



Par exemple, tu ne peux pas de façon déclarative dire que la largeur d’un rectangle est égale à sa hauteur pour en faire un carré. En QML, un tel carré resterait carré si sa largeur change au cours du temps.



Dans le même genre, en HTML/CSS c’est très compliqué de dire qu’un rectangle à son bord gauche à droite d’un premier élément et son bord droit à gauche d’un second élément et de faire en sorte que lorsque les deux éléments se rapprochent ou s’éloignent le rectangle continue à prendre l’espace entre les deux éléments.

C’est possible de s’en sortir maintenant avec des flexbox mais c’est quand même la misère à déclarer par rapport à QML. Il faut notamment déclarer le comportement d’un élément sur son conteneur et non sur l’élément lui même et du coup on est obligé d’avoir un élément conteneur qui souvent ne sert qu’à la mise en forme.

&nbsp;









megabigbug a écrit :



Non, le CSS3 ne permet pas de faire ce que fait QML.



Pour connaître les deux domaines il me paraît plus que probable que tu aies une bonne expérience en matière de création d’UI et une expérience quasi inexistante en matière de conception web.

C’est flagrant: l’ensemble de tes raisonnement se fondent sur les principes et les besoins relatifs à la création de ce que tu connais: les UI.




Sauf que HTML/CSS c'est pas pour faire des UI pour des applications ; c'est fait pour faire ... des pages web. Or les pages web ont un contenu dont la nature est différente, un objectif différent, dont les terminaux, leur diversité, leurs interactions sont différents, etc...      






En gros tu ressembles à un charpentier qui plante des clous toute la journée. Et ne jure que par les marteaux comme 'outil ultime'. Et tu nous expliques que les mécaniciens ont tort d'utiliser des tournevis pour leur tâches, parce qu'un marteau c'est quand même vachement mieux pour planter des clous.








brazomyna a écrit :



En gros tu ressembles à un charpentier qui ne jure que par les marteaux comme ‘outil ultime’. Et tu nous expliques que les mécaniciens ont tort d’utiliser des tournevis pour leur tâches, parce qu’un marteau c’est quand même vachement mieux pour planter des clous.





Justement, aujourd’hui, les mécaniciens se mettent tous à planter des clous (font des UI d’applications avec des technos web) et passent de moins en moins de temps à serrer des vis (créer du contenu web).



Au vu de cette tendance, c’est normale que je fasse la remarque qu’ils n’utilisent pas le bon outil.









brazomyna a écrit :



C’est flagrant: l’ensemble de tes raisonnement se fondent sur les principes et les besoins relatifs à la création de ce que tu connais: les UI.&nbsp;





Mon second exemple décrivait plus ou moins un layout 3 colonnes. Le genre de chose vraiment commun dans les sites Web et qui pourtant est resté longtemps difficile à faire en HTML/CSS sans bidouilles et même aujourd’hui avec les flexbox je trouve que c’est encore compliqué pour faire une chose aussi basique.









lossendae a écrit :



Ca doit dependre de ta formation.&nbsp;



Je trouve le couple HTML + CSS tres simple à utiliser.&nbsp;

Et honnêtement, faire du style en JS, c’est à vomir… du moins pour le peu que j’ai essayé avec react + jsx.





Le QML n’est pas complètement du JS, c’est un language de description qui pour les bindings utilise du js.

Les bindings sont des fonctions exécutées automatiquement à chaque fois qu’une des propriétés que son code utilise change.



Si tu modifie la propriété width d’un élément A tous les autres éléments qui ont des propriétés qui dépendent de A.width se verront mis à jour correctement.



Les gros avantages sont de ne pas avoir à déclarer de callback ou autre, donc ça fait moins de code et les valeurs sont réévaluées dans le bon ordre en fonction des dépendances.

&nbsp;





brazomyna a écrit :



Pour connaître les deux domaines il me paraît plus que probable que tu aies une bonne expérience en matière de création d’UI et une expérience quasi inexistante en matière de conception web.

C’est flagrant: l’ensemble de tes raisonnement se fondent sur les principes et les besoins relatifs à la création de ce que tu connais: les UI.




 Sauf que HTML/CSS c'est pas pour faire des UI pour des applications ; c'est fait pour faire ... des pages web. Or les pages web ont un contenu dont la nature est différente, un objectif différent, dont les terminaux, leur diversité, leurs interactions sont différents, etc...       






 En gros tu ressembles à un charpentier qui plante des clous toute la journée. Et ne jure que par les marteaux comme 'outil ultime'. Et tu nous expliques que les mécaniciens ont tort d'utiliser des tournevis pour leur tâches, parce qu'un marteau c'est quand même vachement mieux pour planter des clous.







Justement de plus en plus d’applications sont faites en web et une UI à aussi besoin de pouvoir afficher des données statique (documents). Le QML est bon à la fois pour créer de l’UI dynamique et des documents statiques.

Les interfaces web doivent aujourd’hui passer d’un écran PC à un smartphone, en html généralement c’est fait en faisant des pages web voir sites différents. En QML on peux le faire qu’une fois pour supporter l’ensemble des plateformes.

Franchement j’ai testé boostrap, ça à beau être pas mal, c’est super lourd, il faut un i7,… pour afficher une page avec un peu de contenu.

&nbsp;

J’ai quand même l’impression que ce sont ces technologies web qui font que les navigateurs consomme autant de mémoire. Leur moteur est blindé de code pour gérer la compatibilité,…









flamaros a écrit :



j’ai testé boostrap, ça à beau être pas mal, c’est super lourd, il faut un i7,… pour afficher une page avec un peu de contenu.





Je crois qu’à ce stade le débat n’est plus nécessaire. <img data-src=" />



Il ne me reste qu’aà te souhaiter bon courage pour ta démarche d’évangélisation de Qml comme techno remplaçante de HTML/CSS

&nbsp;









damaki a écrit :



Et soit dit en passsant, pour Chrome, c’est pas évident de calculer son utilisation mémoire réelle à cause des process séparés et de la mémoire partagée.





Il suffit d’ouvrir le gestionnaire des tâches de chrome ;)







seblutfr a écrit :



C’est l’éternel problème : à chaque news, il y a des comparaisons de conso mémoire entre INpactiens, mais sans protocole précis. Tout dépend des pages ouvertes, de leur contenu, de la navigation effectuée, etc.

Pour être précis, il faudrait simplement un jour que quelqu’un fasse le même test avec les mêmes pages sur 2 navigateurs d’un même PC.





Pour ma part, le protocole c’est accéder à Gmail sur l’interface Inbox (pas leur truc tout pourri avec les onglets social, promotion, …).

Simple non?

Bon, il faut bien avouer que firefox ne fait pas mieux, ni pire.



Quand je parlais de design, je pensais à la forme du contenu, et non pas son style. Le style lui pourrait provenir du système. GTK+/autre n’est pas “lourd”, c’est simplement déjà présent dans le système. Je pense plus à quelque chose indépendant et compatible.


Je me vois difficilement faire confiance à un navigateur dire la vérité sur une caractéristique qui définit selon moi sa performance. L’OS ne ment pas.