Une structure d'élément E est instanciée en fonction du nom ou de l'identifiant d'élément lu dans le fichier XML ou le fichier binaire. Cet élément E est ajouté dans l'arbre de scène comme enfant de l'élément parent P. Ensuite, la lecture des attributs débute et la valeur de l'attribut est stockée dans une structure décrite dans le Code 7.7. Cependant, la lecture de certains attributs peut nécessiter d'abord la lecture d'autres éléments de la scène. Par exemple, si l'élément en cours de lecture est un élément d'animation, la lecture des attributs décrivant les valeurs d'interpolation ne peut être effectuée que lorsque le type de ces attributs est connu, c'est-à-dire quand l'élément cible de l'animation a été lu. Le même problème se pose pour la lecture des attributs de temps ou pour les attributs référençant un élément (comme l'attribut xlink:href). L'interprétation de ces attributs est donc différée, et à chaque nouvel élément lu, qui possède un identifiant, elle est tentée à nouveau.
Cette méthode présente donc l'avantage théorique d'une réduction de la mémoire utilisée mais l'accès à un attribut nécessite le parcours de la liste des attributs spécifiés. Il faut noter que seuls les accès en lecture sont affectés, c'est-à-dire durant la phase de composition. Or, pendant cette phase, tous les attributs de l'élément sont lus, nous avons donc considéré une façon simple de limiter l'augmentation du temps de lecture de ces attributs, en utilisant une structure contenant tous les attributs possibles
Chapitre 7 – Implémentation optimisée d'un lecteur de scènes multimédia animées et interactive
dans le langage SVG. Cette structure est créée temporairement quand on souhaite accéder à un ensemble d'attributs d'un même élément. Grâce à cette structure, le parcours des attributs spécifiés n'est effectué qu'une seule fois, pour remplir cette structure.
7.2.2.6 Résultats et limitations
Suite à ce travail d'implémentation, nous avons pu vérifier les différents points suivants :
• Une réduction de la consommation mémoire d'un facteur 4 en moyenne, facteur qui augmente avec la taille du contenu, entre la solution précédente (numérotée 1) et cette solution (numérotée 2). Quelques résultats chiffrés sont indiqués dans le Tableau 7.1. On note également une légère diminution du temps de lecture, vraisemblablement due à une politique d'allocation mémoire plus efficace.
Consommation Mémoire (Ko) Séquence SVG Nombre d'éléments Nombre d'attributs
1 2 Plan.svg 287 059 246 296 259 120 56 233 GareDuNord.svg 13 263 50 891 13 903 5 801 Plan_layer_1.svg 12 896 27 659 13 845 5 206 Face_frame_1.svg 490 980 555 228 Cee.svg 81 99 407 306 Butterfly.svg 4 14 92 90
Tableau 7.1 – Réduction de la consommation mémoire
• La rapidité de notre algorithme de lecture par rapport à des implémentations de référence comme le montre le Tableau 7.2. Les séquences ont été modifiées, en plaçant tous les éléments dans un groupe dont la propriété d'affichage display indique qu'ils ne doivent pas être rendus, afin de tenter de comparer uniquement les phases de lecture des implémentations.
Séquence SVG GPAC ASV 6.0 Opera 9.10 Firefox 2.0.0.1 Renesis 0.2.0
Plan_layer_1.svg 1 s / 8 228 Ko 5 s / 47 100 Ko 5 s / 27 364 Ko 17s / 39 668 Ko 3 s / 28 996 Ko
Plan.svg 7 s / 100 Mo N/A 24 s / 202 Mo N/A 5 s / 115 Mo
GareDuNord.svg 1 s / 9 Mo 1 s / 40 Mo 2 s / 18 Mo 4 s / 23 Mo <1s / 13 Mo
Tableau 7.2 – Comparaison du temps de lecture et de la consommation mémoire pour différentes implémentations de référence
Descriptions de scènes multimédia : représentations et optimisations
- 158 -
• Une augmentation négligeable du temps de composition d'un élément SVG suite à l'accès aux attributs dynamiques grâce à la structure regroupant 'à plat' tous les attributs possible en SVG. Par exemple, sur la séquence 'plan.svg' qui comporte 246 296 attributs, le temps d'accès à ces attributs durant la phase de composition est mesuré comme représentant 0.1% du temps total d'un cycle de présentation.
7.2.3 Synthèse sur l'efficacité de la lecture de scènes
Dans cette partie, nous avons tout d'abord redémontré, sur des contenus SVG, que l'utilisation d'un lecteur de scènes binaires était profitable notamment pour la réduction de la consommation mémoire et la rapidité de lecture. Nous nous sommes ensuite intéressés aux structures d'arbres de scènes générés en sortie de ce lecteur. Nous avons analysé les langages BIFS et SVG afin de comparer la structuration des primitives du langage. Nous avons souligné les avantages et inconvénients de chaque solution dans le domaine de la création de contenu et celui de la consommation mémoire. Nous avons exploité cette analyse afin de déterminer une structuration efficace des objets mémoires nécessaires à la lecture des scènes SVG. Cette structuration s'appuie sur des listes d'attributs dynamiquement alloués. Elle permet une consommation mémoire optimale, car seuls les attributs spécifiés sont effectivement alloués; et un accès relativement rapide aux données pour la lecture et l'écriture.
7.3 Composition optimisée de scènes SVG
L'étape de composition est l'étape dans le cycle de présentation qui suit la lecture/décodage du contenu. Cette étape est une étape supplémentaire nécessaire par rapport à la visualisation de média classique (vidéo, audio), il est donc intéressant de décrire plus en détail son fonctionnement afin de bien comprendre les enjeux en terme de performance.
7.3.1 Fonctionnement de la phase de composition
Le but de cette étape est de produire une représentation modifiée de la scène, à chaque instant de présentation, à partir de la représentation mémoire de la scène issue du processus de lecture. Le module de composition doit, à chaque rafraîchissement de l'écran, déterminer les paramètres (aspects, formes, positions, …) des différents éléments audiovisuels en fonction des animations, de l'interactivité, éventuellement des mises à jours issues des flux de descriptions de scènes.
Cette étape peut parfois être intégrée au décodage de la scène, dans certains cas, notamment quand la scène est statique (sans animation, sans interactivité) et quand elle n’utilise pas de média externes (image, sons, vidéos …), mais ce n'est pas le cas général. Dans le cas général, le module de composition est un module séparé du module de décodage pour deux raisons :
• Tout d’abord, comme son nom l’indique, il s’agit de composer des données issues de plusieurs sources, de plusieurs décodeurs (vidéo, audio, images fixes, texte), qui ne fonctionnent pas
Chapitre 7 – Implémentation optimisée d'un lecteur de scènes multimédia animées et interactive
nécessairement à la même cadence (exemple : un décodeur vidéo à 15 Hz et un décodeur vidéo à 25 Hz).
• Ensuite, même dans le cas d’un contenu ne nécessitant aucun décodeur annexe, la scène pouvant évoluer dans le temps, dans le cas d’animations ou d’interactions utilisateur, il est nécessaire de recomposer la scène alors même que le lecteur/décodeur de scène n’a pas transmis de données supplémentaires.
7.3.2 Rapidité de composition
La composition implique, à chaque cycle de présentation, un parcours de la représentation mémoire de l'arbre de scène et la lecture des attributs des éléments de cet arbre. Pour obtenir une expérience fluide, notamment en cas d’animation et d’interactivité, nous l'avons dit, il faut que les cycles de présentation soient très courts, donc notamment que l’étape de composition soit la plus rapide possible. Nous avons, dans la partie précédente, décrit comme les objets mémoire étaient structurés. Nous nous intéressons ici aux parcours de ces objets et aux traitements associés qui peuvent être également complexes et coûteux en temps.
Pour limiter le temps de la phase de composition, on peut :
• limiter le temps total passé dans la phase de composition, en limitant le nombre de parcours de la scène par seconde mais au détriment de la fluidité;
• ou pour chaque parcours, limiter l’ampleur du parcours, c'est-à-dire la profondeur de la traversée de l’arbre de scène;
• et enfin, limiter les opérations à effectuer au niveau de chaque nœud de l'arbre.
Différents travaux ont été publiés sur la question. Le groupe de travail SVG réfléchit, dans le cadre de la standardisation du profil Full de la version 1.2 du langage SVG, à l'utilisation d'indicateurs des parties statiques de la scène. La version du 27 octobre 2004 [69] mentionne les propriétés cache et
static décrivant respectivement les parties de la scène devant être retracées souvent et celles qui a priori ne seront pas modifiées. D'autres travaux s'orientent vers la détection des parties de la représentation interne qui n’évolue pas d’un cycle à l’autre afin de ne pas les parcourir au cycle suivant. Par exemple, il n’est pas nécessaire de parcourir les parties de la scène non affectées par l’animation ou l’interaction. Cependant, la détection et le suivi de ces zones ‘statiques’ de la scène n’est pas un processus simple. Il faut notamment mettre en place des caches qui peuvent être coûteux en mémoire. De plus, la détection et le suivi des zones non modifiées nécessitent de nombreux tests qui ralentissent l’exécution. Donc, si la scène est très volumineuse, il peut arriver qu’une recomposition complète soit plus efficace qu’un suivi et une recomposition des changements. Un
Descriptions de scènes multimédia : représentations et optimisations
- 160 -
compromis doit être trouvé entre capacité mémoire et vitesse d’exécution. On pourra également lire [01] à ce sujet.
Notre démarche s'inscrit également dans cette optique de limiter l'ampleur des parcours et traitements de l'arbre. Pour cela, nous considérons la composition d'une scène SVG comme le traitement de trois types de primitives :
• les primitives temporelles, c'est-à-dire les animations et les éléments audiovisuels;
• les primitives liées aux interactions utilisateur, c'est-à-dire les écouteurs, les gestionnaires d'évènements et les scripts;
• et enfin, les primitives graphiques et celles relatives au positionnement spatial des primitives graphiques.
Toutes ces primitives nécessitent un traitement spécifique durant la phase de composition. Une approche simple de composition consisterait à parcourir l'arbre de scène et à appliquer ce traitement spécifique à chaque élément au moment de la traversée de cet élément. Il est évident que cette approche n'est pas satisfaisante car si la scène contient beaucoup d'objets graphiques et peu d'animations, les animations ayant besoin d'être parcourues régulièrement pour atteindre une fluidité satisfaisante, les primitives graphiques seraient alors inutilement parcourues.
Cependant, il n'est pas immédiat que, dans toutes les scènes, du fait de mécanismes d'héritage et d'interactivité, les primitives temporelles, d'interactivité et graphiques peuvent être traitées séparément. Nous analysons ici ces trois catégories de primitives afin de montrer qu'il est possible de séparer le traitement entier de l'arbre en plusieurs traitements disjoints de ces trois catégories pour obtenir un algorithme de composition des scènes SVG plus rapide que l'approche simple précédente.
7.3.2.1 Traitement des éléments temporels
Pour les éléments temporels, le traitement effectué dans la phase de composition peut se dérouler comme suit :
• Déterminer si un élément temporel est actif, par la construction des intervalles d'activité à partir des valeurs temporelles de début et de fin d'activation, et générer les évènements correspondants (début, fin, répétition).
• Dans le cas où un intervalle d'activité existe :
o Calculer la fraction de temps écoulé dans la durée simple depuis le début de cette période d'activité et le nombre de répétitions qui ont eu lieu.
o Appliquer un traitement associé. Dans le cas d'un élément d'animation, ce traitement est le calcul de la valeur d'interpolation et la modification de la scène. Dans le cas
Chapitre 7 – Implémentation optimisée d'un lecteur de scènes multimédia animées et interactive
d'un élément vidéo, il consiste à afficher l'image précise correspondant à l'instant de composition.
La première partie est une tâche relativement complexe. L'activité d'un élément peut en effet dépendre d'évènements qui se produisent dans d'autres parties de l'arbre de scène, comme dans l'exemple du