News Xulfr

Tout d'abord, l'accélération matérielle. La version windows de Gecko utilise maintenant, expérimentalement (dans les nightlies), Direct2D pour certaines opérations graphique. En fait ce support a été ajouté par Mozilla dans la bibliothèque graphique Cairo, utilisée par d'autres projets en plus de Gecko. Le support pour OpenGL 2.1 est prévu pour les autres plate-formes. Il y a déjà un support pour OpenGL, mais uniquement au niveau de l'API Canvas3D (WebGL), qui permet de faire de la 3D via l'élément Canvas (voir notre précédente news à ce sujet).

Ce support de l'accélération graphique servira à tout ce qui est "dessin 2D". Mais n'est pas suffisant. Le moteur de rendu dans Gecko est en train d'être ré-architecturé, en utilisant un système de layers. Chaque type de layer pourra avoir son propre type d'accélération graphique. C'est ainsi que les layers de type "video" pourront être accélérées en utilisant les spécificités des cartes graphiques pour les vidéos. Ainsi chaque partie d'une page web sera affichée d'une manière optimum. Pour en savoir plus, je vous recommande la lecture de cet article paru sur libre-ouvert, expliquant plus en détails ce système de layer.

Autre chantier, le moteur javascript. Jusqu'à la version 3.0 de Firefox, nous avions simplement le moteur SpiderMonkey, qui interprète à la volée le javascript, le transforme en bytecode et exécute ce bytecode. Dans la version 3.5, une évolution est apparu : le tracing. Le moteur JS (appelé TraceMonkey) repère les parties de codes répétitives, tout en tentant de détecter les types des valeurs utilisées. À partir de cela, il génère du code machine optimisé, ce qui évite de réinterpréter le javascript à chaque passe d'une boucle. Ce traitement est effectué précisément par Nanojit, un composant issue du projet Tamarin. Cependant, tout le code javascript ne peut être optimisé de la sorte, ce qui ne permet pas d'avoir des grandes améliorations de performances dans certain cas.

La prochaine évolution, pour le code qui ne peut être exécuté par le biais du tracing, va être de transformer celui-ci en code machine. C'est le projet JägerMonkey. Ils vont réutiliser pour cela Nitro Assembler, un "compilateur" issue de la version de webkit issue d'Apple. Celui-ci ne fait pas les mêmes types d'optimisations que NanoJit, mais le résultat sera le même : exécution direct de code machine. Il se pourrait bien que Mozilla rattrape, voir dépasse ses concurrents, en particulier le moteur V8.

Pour plus de détails, voir cet article en anglais du site hack.mozilla.org.