Ce n'est pas parce que c'est fait en javascript, qu'il faut imputer les problèmes de perfs à l'implémentation javascript.
Déjà, Javascript, ce n'est qu'un langage. Prend la spec d'Ecmascript, et tu n'y trouveras nulle part référence à DOM, canvas etc. En d'autres terme, un moteur javascript, ça n'implémente que l'interprétation de la syntaxe JS, quelques objets de base (Math, Array, String, Number etc...), et tout le reste que l'on utilise très souvent en JS (comme l'objet window, le DOM etc), ce ne sont que des API implémentés dans des libs à coté (rien à voir avec le JS donc), et importé dans le langage JS
Bref, dans ce genre d'application très graphique, le javascript n'a que peu de part de responsabilité dans les problèmes de perfs. Surtout que TraceMonkey (moteur de Firefox), compile en code machine pur tout ce qui est calcul mathématique js avant exécution (en particulier dans les boucles).
Si on veut un responsable sur les perfs, et dans une appli web comme celle là, il faut se tourner donc vers le DOM, et plus particulièrement ici vers la balise canvas.
Chez Mozilla, on sait que la couche de binding DOM <-> javascript n'est pas des plus performantes, et dans le trunk, (et la branche Fx 3.6 je crois), il y a eu des améliorations assez significatives en ce sens.
Ensuite, canvas. Dans Firefox, canvas, ce n'est qu'une API haut niveau au dessus de la bibliothèque Cairo (http://cairographics.org/ ). Autant dire que les mesure de perfs purement graphiques sont à imputer à Cairo. Reste à savoir dans quel mesure Cairo contribue à la dégradation des perfs en globalité.
Pour conclure, ne pas confondre javascript et les dizaines de composants que contient un navigateur.
[^] # Re: c'est bluffant
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal JSNES, un émulateur de NES en Javascript. Évalué à 10.
Déjà, Javascript, ce n'est qu'un langage. Prend la spec d'Ecmascript, et tu n'y trouveras nulle part référence à DOM, canvas etc. En d'autres terme, un moteur javascript, ça n'implémente que l'interprétation de la syntaxe JS, quelques objets de base (Math, Array, String, Number etc...), et tout le reste que l'on utilise très souvent en JS (comme l'objet window, le DOM etc), ce ne sont que des API implémentés dans des libs à coté (rien à voir avec le JS donc), et importé dans le langage JS
Bref, dans ce genre d'application très graphique, le javascript n'a que peu de part de responsabilité dans les problèmes de perfs. Surtout que TraceMonkey (moteur de Firefox), compile en code machine pur tout ce qui est calcul mathématique js avant exécution (en particulier dans les boucles).
Si on veut un responsable sur les perfs, et dans une appli web comme celle là, il faut se tourner donc vers le DOM, et plus particulièrement ici vers la balise canvas.
Chez Mozilla, on sait que la couche de binding DOM <-> javascript n'est pas des plus performantes, et dans le trunk, (et la branche Fx 3.6 je crois), il y a eu des améliorations assez significatives en ce sens.
Ensuite, canvas. Dans Firefox, canvas, ce n'est qu'une API haut niveau au dessus de la bibliothèque Cairo (http://cairographics.org/ ). Autant dire que les mesure de perfs purement graphiques sont à imputer à Cairo. Reste à savoir dans quel mesure Cairo contribue à la dégradation des perfs en globalité.
Pour conclure, ne pas confondre javascript et les dizaines de composants que contient un navigateur.