Fonctionnement

structure des données

L'affichage d'un document repose sur plusieurs structures de données en mémoire.

Il y a d'abord les objets "content" (répertoire content/). Quand Gecko parse un fichier XML/HTML, il crée un objet "content" pour chaque balise rencontrée dans le document. Ces objets "content" ont un certain nombre de propriétés et de méthodes pour les manipuler. Ils contiennent entre autres toutes les informations qui sont disponibles via les interfaces DOM (qui sont elles définies dans dom/ ainsi que des objets DOM héritant de content). Pour chaque document chargé, il y a donc un arbre d'objets "content".

Parallèlement à ça, pour l'affichage proprement dit, gecko crée un autre arbre : un arbre d'objets "frame". Une frame, dans le jargon Gecko, est un objet destiné à dessiner quelque chose de précis : une bordure, un rectangle coloré, une image, un sous document, le contenu d'un plugin (genre flash etc..) etc.. Il y a une relation entre l'arbre "content" et l'arbre "frame" : à chaque objet "content" (donc à chaque balise du document), il correspond une ou plusieurs frames, en fonction de la complexité de l'affichage de l'élément, mais aussi des styles CSS qui lui sont appliqués.

Ces objets frames possèdent une multitude de propriétés (ex: une largeur, une hauteur, une couleur...) dont les valeurs dépendent des styles css déclarés, de valeurs dans les attributs de l'élément auquel est rattaché la frame, et du contexte d'affichage (zoom, taille de la fenêtre, position/propriétés des frames adjacentes etc..). Toutes les frames, ainsi que le moteur de rendu en lui même est dans le répertoire layout/. On y trouve aussi le parser CSS.

TODO : expliquer le DocShell et webshell

Affichage

Enfin quand une frame doit être affichée (en fonction de ses caractéristiques bien sûr), il est utilisé les bibliothèques graphiques dans le répertoire gfx/, entre autre Cairo, ou encore les bibliothèques plus spécialisée, dans modules/ comme par exemple la libpr0n, pour l'affichage des images (pas sûr que ce soit encore d'actualité depuis l'utilisation de cairo).

Parfois, il faut utiliser des propriétés propres à l'environnement graphique du système d'exploitation, comme les couleurs par défaut d'un bouton, l'aspect graphique d'un bouton etc. Dans ce cas les frames appellent les bibliothèques propres à chaque système, situées dans widgets/.

Complexité du moteur de rendu : le reflow.

Les propriétés d'une frame dépendant des propriétés d'autres frames, vous imaginez donc la complexité des calculs à faire, en particulier quand on modifie le contexte. Par exemple, l'utilisateur redimensionne la fenêtre : il faut recalculer toutes les frames, détecter si une frame correspondant à un mot, une ligne de texte, doit être reconstruite à cause du fait que ladite phrase doit être coupée en deux lignes plutôt qu'une auparavant (on a réduit la fenêtre par exemple).

Ou autre exemple, sur un simple :hover d'un élement, on ajoute une bordure plus grosse. Opération qui semble anodine mais qui peu avoir de grosse répercussion sur l'affichage. Au passage de la souris, il faut donc modifier la largeur de la bordure. Mais cette modification entraîne peut être un redimensionnement des frames qui sont autour, voir même une reconstruction. Du genre, la bordure de droite, qui devient plus grosse "pousse" la frame de droite qui contient du texte. Celle-ci est alors certainement obligé de se rétrécir. Mais imaginons qu'elle devienne alors trop petite pour contenir son texte sur une seule ligne, donc il faut créer une frame en dessous qui contiendra la deuxième partie de la phrase, ce qui va pousser les frames du dessous vers le bas, et donc provoquer d'autres changements etc... À cela il faut tenir compte des propriétés du genre overflow, des types de positionnements de chaque élement (float, absolute et cie).

Tout ce processus de calcul est ce que l'on appelle le "reflow", dont le code dans Gecko 1.9 a pratiquement été réécrit entièrement.

En savoir plus

Il y a quelques documents sur http://www.mozilla.org/newlayout/