Résultats et limitations

Notre algorithme possède deux limitations que nous exposons ici : la première liée aux interfaces de manipulation des arbres de scènes SVG et la seconde liée à des cas particuliers d'imbrication héritage/animation.

7.3.4.1 Limitation dans la manipulation de l'arbre de scène

Comme nous l'avons indiqué auparavant, deux ensembles d'interfaces sont actuellement disponibles dans le langage SVG : DOM ou Micro DOM. Nous présentons ici notre analyse de la complexité de ces accès, les limitations de notre proposition dans ce domaine ainsi que les raisons pour lesquelles notre proposition reste toujours satisfaisante.

7.3.4.2 L'interface DOM

Un arbre DOM est, de manière simplifiée, un arbre composé de nœuds correspondant aux éléments présents dans un fichier XML. De plus, chaque attribut spécifié dans le document XML correspond à une structure d'attribut DOM, associé à ce nœud, et dont la valeur est une chaîne de caractère. S'il n'existe pas de grammaire attachée au document, les attributs non spécifiés dans le document XML ne sont pas présents dans la structure de nœud DOM. En revanche, si le document XML possède une grammaire associée sous la forme d'une DTD, et que celle-ci définit une valeur par défaut pour un attribut, une structure d'attribut DOM est créée avec cette valeur par défaut, et cette structure est attachée au nœud DOM en question.

Ces particularités de l'interface DOM posent des problèmes :

• Le premier problème est l'utilisation de chaînes de caractères. On peut décider de stocker les valeurs sous forme typée (nombre entier, booléen, nombre décimal, triplet de couleurs), comme c'est le cas dans notre proposition, mais à chaque accès à un attribut, le module de composition devra convertir la chaîne en représentation typée ou inversement. Ainsi, en réduisant la consommation mémoire grâce à l'utilisation de valeurs typées, on réduit également la rapidité d'accès aux données.

• Le second problème concerne l'accès aux attributs quand ils ne sont pas spécifiés dans le document. L'interface DOM indique, dans ce cas, que la fonction getAttribute doit retourner une chaîne de caractère vide (si aucune grammaire n'est associée). Cela oblige une implémentation à maintenir d'une part le fait qu'une grammaire soit associée et le fait qu'un attribut ait été spécifié ou non.

Notre proposition n'est donc pas optimale pour un interfaçage avec l'API DOM. Cependant, l'interface DOM est remplacée pour les raisons exposées précédemment, dans le profil Tiny de la version 1.2 du langage SVG, par une interface de programmation plus simple qui ne pose pas ces problèmes et pour

Descriptions de scènes multimédia : représentations et optimisations

- 168 -

laquelle il est plus pertinent d'évaluer notre algorithme de composition. Cette interface s'appelle MicroDOM.

7.3.4.3 L'interface MicroDOM

L'interface MicroDOM définit la notion de Trait pour accéder aux attributs en s'appuyant sur deux points :

• Tout d'abord, la spécification offre la possibilité d'accéder aux attributs en écriture et en lecture par des fonctions typées. De ce fait, notre choix de ne pas utiliser une représentation des attributs sous forme de chaîne de caractères pour les valeurs des attributs est compatible.

• Ensuite, les attributs non spécifiés dans le fichier SVG sont représentés dans l'arbre MicroDOM par une structure dont la valeur est effectivement la valeur par défaut définie dans la spécification SVG. Il n'y a pas de distinction entre valeur par défaut et valeur spécifiée. Sur ce point, l'arbre MicroDOM diffère de ce que nous proposons, car nous n'allouons en mémoire que les attributs spécifiés. Cependant, il est possible d'étendre notre implémentation pour retourner une valeur par défaut à une requête d'accès sur un attribut non spécifié.

Chapitre 7 – Implémentation optimisée d'un lecteur de scènes multimédia animées et interactive

Notre structuration des éléments et notre algorithme de composition sont donc compatibles avec l'interface MicroDOM sur ces deux points. Cependant, certains problèmes subsistent. En effet, la spécification SVG indique deux points importants. Elle indique que la valeur retournée par les fonctions getTrait est la valeur de base en cas d'animation, c'est-à-dire la valeur après héritage potentiel, autrement dit la valeur calculée selon la norme CSS. Elle indique également que la valeur retournée par la fonction getPresentationTrait est la valeur de présentation si la valeur est animée. Les différentes valeurs retournées par ces différentes fonctions sont illustrées dans la Figure 7.3.

Les problèmes liés à notre algorithme sont donc les suivants :

• Dans le cadre de notre proposition, nous avons opté pour un arbre de scène dont les attributs stockent la valeur de présentation, ou la valeur spécifiée s'il n'y a pas d'animation. Ainsi la valeur après héritage n'est calculée que temporairement pendant la phase de composition d'un élément (comme nous l'avons décrit précédemment) et nous n'avons donc pas duplication de la mémoire nécessaire par attribut. Il n'est donc pas possible d'obtenir la valeur calculée selon CSS sans effectuer une phase de composition supplémentaire de la racine jusqu'à l'élément en question.

• De même, dans notre proposition, pour obtenir la valeur spécifiée dans le document XML, il faut déterminer si une animation s'applique et si oui, obtenir la valeur de base à partir de la valeur sauvegardée dans la structure d'animation. Ceci suppose donc un accès, possible, mais plus lent à la valeur de base.

Notre proposition présente donc l'inconvénient de ne pas offrir une réponse rapide, dans certains cas, aux appels de fonctions getTrait. Ceci est le résultat du fait que notre implémentation privilégie dans ce cas la consommation mémoire à la rapidité d'accès mais ne constitue pas une incompatibilité avec le modèle MicroDOM.

7.3.4.4 Limitation lié à l'héritage

Une seconde limitation de notre proposition est toujours liée à la norme CSS et à la notion d'héritage. L'héritage a toujours lieu, selon la norme CSS, en descendant l'arbre. Cependant, SVG autorise des éléments à référencer d'autres éléments de l'arbre pour les réutiliser. C'est le cas, par exemple, de l'attribut stroke qui peut pointer vers un élément de type linearGradient. Dans ce cas, le gradient hérite ses propriétés du parent de l'élément gradient et non du parent de l'élément qui le référence.

Dans notre proposition d'algorithme de composition, nous ne traversons que les éléments graphiques visibles, pour limiter la quantité d'éléments traversés dans l'arbre. Dans certains cas d'utilisation de gradient, quand le gradient est défini dans une partie non visible de l'arbre de scène, et que ses

Descriptions de scènes multimédia : représentations et optimisations

- 170 -

propriétés sont héritées, notre proposition conduit à forcer une traversée de l'arbre supplémentaire jusqu'à ce gradient, pour déterminer les valeurs correctes de ces propriétés. Ce cas étant peu fréquent, nous considérons cette limitation comme acceptable.