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.

Cette décision a été prise à cause des trop nombreux problèmes de sécurités que XUL offre sur le web. Les développeurs de Mozilla veulent s'enlever une charge de travail et voudraient profiter de ce temps pour travailler plus sur HTML5 et XBL2. On ne sait pas encore si cette suppression interviendra dans la prochaine version de Firefox ou d'autres version futures. Vous pouvez suivre l'évolution via le bug 546857.

Bien entendu, cette suppression n'intervient que pour les pages web. Il n'est absolument pas question de supprimer XUL pour les extensions ou les applications XULRunner.

Cela va tout de même poser des problèmes pour tout ce qui est démonstration en ligne de XUL (en particulier celles qui sont hébergées sur xulfr.org). Et puis bien sûr, ceux qui auraient développé des applications web en XUL, celles-ci ne fonctionneront plus. Il y a toutefois des alternatives.

1. Il est tout à fait possible de réaliser une extension, comportant le minimum de fichiers, et ouvrant des pages XUL délivrées par un serveur web profitant des privilèges chrome. Par exemple, le nouveau CMS RBSChange utilise une telle technique. Certes, il faut installer une extension, mais l'essentiel de l'application se trouvant sur un serveur web, il n'y a pas besoin de mettre à jour l'extension à chaque évolution.
2. Vous pouvez continuer à profiter du modèle de boîte flexible de XUL, utiliser les propriétés -moz-box-* sur des éléments HTML (ainsi que display:-moz-box;). Ces propriétés CSS sont d'ailleurs spécifiés dans un brouillon du W3C, donc amenées dans le futur à devenir un standard, tout comme -moz-appearance. À noter que Webkit (donc Safari et Chrome) a une implémentation similaire de ces propriétés.

D'ailleurs, les éléments XUL seront conservés dans le DOM par Firefox lors du chargement du document. Rien ne vous empêche de vous faire donc une feuille de style xul.css pour rétablir les propriétés CSS pour XUL. Vous perdrez cependant les comportements et fonctionnalités par défaut des éléments XUL. Et il n'y a pas vraiment d'alternative. HTML5 prévoit bien quelques balises pour les menus et commandes (pas encore implémenté dans Firefox), mais rien pour un équivalent des templates, des trees etc...

Vous pouvez télécharger XulRunner sur cette page et lire les notes de cette sortie.

Le coeur de Firefox 3.6, gecko 1.9.2, apporte de nombreuses nouveautés au niveau des technologies web, et permettent, avec les autres avancées HTML5 présentes dans les versions précédentes de Firefox, de réaliser maintenant des applications web vraiment puissante.

Pour le montrer, Paul Rouget vient de sortir une nouvelle démo. Cependant, c'est plus qu'une démo, c'est une véritable petite application concrète.

Il s'agit d'un outil, qui permet d'envoyer des images sur twitpic et comportant un éditeur d'image. Vous sélectionnez les images que vous voulez envoyer, vous les retouchez éventuellement, et vous les envoyez. Visualisez la video, c'est carrément génial, d'un point de vue technique. C'est du jamais vu dans une application web HTML (si on met de coté les applet java ou flash, souvent lourdes et peu ergonomiques).

Coté technique donc, voici ce qui est utilisé :

• HTML5 Canvas: on ne présente plus l'élement <canvas>, qui permet d'avoir une zone dans la page web où l'on peut "dessiner" programmativement. Les images que l'on a glisser dans l'application sont "injectées" dans un canvas. Cela permet alors de les modifier, de proposer à l'utilisateur une mini application de retouche, avec des fonctions de découpage, de décoration, de mirroir etc. Avec Canvas, on peut aller très très loin. Voir par exemple cet outil, sketchpad, un paint-like bien plus beau que l'original :-)
• HTML5 Drag and Drop: Paul utilise les évènements drag-and-drop, pour permettre, d'une part, de glisser des fichiers de votre bureau ou explorateur de fichiers vers l'application, mais aussi de glisser les images à l'intérieur de l'application entre les différentes fonctionnalités (glisser une image précédemment sélectionnée vers la poubelle par exemple).
• File API : permet dans l'application d'avoir des informations sur les fichiers, à partir de ce qui est indiqué dans un <input type="file"> ou un évènement drag and drop qui concerne un fichier. Ça permet à l'application de réagir ensuite en fonction du type du fichier, de sa taille etc..
• HTML5 localStorage: localStorage est un objet javascript qui permet de stocker ce que l'on veut, durablement, coté client. Il est utilisé ici pour stocker les images sélectionnées, en attendant de les envoyer vers twitpic. L'image, affichée en fait via un canvas (ce qui permet de la modifier), est en fait transformée en data URL. Cette URL est alors stockée dans localeStorage.
• HTML5 Application Cache : toute la machinerie permettant de continuer à faire fonctionner l'application même en étant déconnecté, est utilisée. En particulier, un manifest "offline" est utilisé pour indiquer les fichiers de ressources (js, css) à stocker durablement dans le cache du navigateur, de manière à pouvoir recharger l'application, même en étant déconnecté. En fait, c'est comme si l'application était stockée en local. De plus, les évènements offline et online sont écoutés, pour pouvoir autoriser ou non la publication des images.
• Cross Site xmlHTTPRequest, un mécanisme http permettant d'autoriser ou non à une application web (ici la demo) de communiquer avec une autre application web (ici twitpic).

Toutes ces technologies, dorénavant présente dans Firefox 3.6 et déjà plus ou moins dans d'autres navigateurs (à vérifir, si ça ne l'est pas encore, ça ne devrait pas tarder), offrent de bien belles perspectives en matières d'applications web puissantes et agréables à utiliser, que ce soit pour les CMS ou pour les sites e-commerce.

Bien sûr, tout ceci est aussi utilisable dans une extension, facilitant alors leur développement.

Pour en savoir plus sur les nouvelles possibilités de Firefox 3.6/Gecko 1.9.2, n'hésitez pas à consulter la page Firefox 3.6 for developers.

NB : Ficaire n'est pas un gros mot malgré son nom populaire d'herbe aux hémorroïdes.