Proposition pour le suivi des objets modifiés en SVG

Comme nous l'avons vu dans les chapitres précédents, les sources de modification dans une scène sont les animations et l'interactivité. Afin de détecter les modifications qui ont lieu sur une scène entre deux phases de rendu consécutives, notre algorithme de rendu s'appuie premièrement sur un suivi des éléments d'animation actifs et des scripts actifs. Pour chaque attribut animé, nous déterminons si le résultat cumulé des animations, tel que décrit dans le chapitre 3, a produit une valeur différente par

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

- 174 -

rapport au cycle précédent. Si c'est le cas, nous marquons l'élément concerné comme modifié. De même, à chaque exécution de script, si un élément est modifié, nous marquons l'élément.

La difficulté réside dans la façon de marquer le nœud. En effet, nous avons vu que, pour des raisons d'efficacité, la détection des modifications de liste d'affichage s'appuient sur trois critères de comparaisons : forme géométrique, apparence et position. Par exemple, si seule la couleur de remplissage a été modifiée, il ne faut pas recalculer la géométrie de l'objet ou les propriétés de contour car ces opérations peuvent être coûteuses. Nous utilisons donc un marqueur pour déterminer si la géométrie de l'élément graphique est modifiée (GEOMETRY_DIRTY). C'est par exemple le cas si on anime l'attribut width d'un rectangle ou si on modifie la liste des points composant un polygone. Pour ce qui est de la position, nous effectuons directement la comparaison entre les matrices de positionnement et n'utilisons pas de marqueur. En revanche, pour suivre les modifications d'apparence, l'utilisation d'un marqueur n'est pas suffisante dans le langage SVG du fait de l'héritage de propriétés. En effet, il faut pouvoir distinguer quel paramètre de l'apparence a été modifié pour retracer un minimum d'objets.

Notre algorithme considère donc les marqueurs de modification d'apparence suivants :

COLOR_DIRTY, DISPLAYALIGN_DIRTY, FILL_DIRTY, FILLOPACITY_DIRTY, FILLRULE_DIRTY, FONTFAMILY_DIRTY, FONTSIZE_DIRTY, FONTSTYLE_DIRTY,

FONTVARIANT_DIRTY, FONTWEIGHT_DIRTY, LINEINCREMENT_DIRTY, OPACITY_DIRTY, SOLIDCOLOR_DIRTY, SOLIDOPACITY_DIRTY, STOPCOLOR_DIRTY, STOPOPACITY_DIRTY, STROKE_DIRTY, STROKEDASHARRAY_DIRTY, STROKEDASHOFFSET_DIRTY,

STROKELINECAP_DIRTY, STROKELINEJOIN_DIRTY, STROKEMITERLIMIT_DIRTY, STROKEOPACITY_DIRTY, STROKEWIDTH_DIRTY, TEXTALIGN_DIRTY,

TEXTANCHOR_DIRTY, VECTOREFFECT_DIRTY.

Nous utilisons un marqueur spécifique par propriété. Ces marqueurs sont hérités le long de l'arbre DOM de la même manière que la propriété correspondante. Par exemple, si un élément de l'arbre DOM est marqué avec le marqueur STROKEWIDTH_DIRTY, cela signifie que la propriété stroke- width a été animée ou modifiée par script sur cet élément ou sur un élément parent. Si les enfants de cet élément utilisent la valeur inherit pour cette propriété, ces enfants seront à leur tour marqués avec le marqueur STROKEWIDTH_DIRTY. En revanche, si un enfant spécifie pour cette propriété une valeur différente de inherit, le marqueur ne sera pas hérité et l'objet ne sera pas rafraîchi.

7.4.4 Résultats et limitations

Nous avons implémenté notre algorithme dans le lecteur GPAC, ce qui nous a permis de valider le fait que le suivi des objets modifiés permet de limiter la taille des zones de l'écran à rafraîchir et donc permet une fréquence de rafraîchissement plus élevée. Par exemple, sur un contenu graphique décrit par un groupe composé d'un rectangle et de 72 cercles, où la propriété de couleur de remplissage est animée au niveau du groupe et où seul le rectangle hérite cette propriété, nous avons mesuré une réduction d'un facteur 9 du temps de rendu entre deux versions du moteur de rendu avec et sans notre

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

proposition. Cependant, il faut noter que la réduction du temps de rendu dépend fortement du contenu et de la manière dont le contenu est créé : du nombre et de la répartition en groupe des objets animés et non animés, ou de la superficie de la fenêtre de visualisation occupée par ces objets.

Notre implémentation présente actuellement deux limitations. La première concerne la quantité de marqueurs. Celle-ci est directement liée au nombre de propriétés possibles sur un élément. Ainsi, dans un contexte de descriptions de scènes mélangeant plusieurs langages comme XHTML, SVG, CSS, où de nombreuses propriétés sont utilisées, le nombre de marqueurs, et donc de tests à chaque phase de rendu, seront très grands.

La seconde limitation concerne l'affichage de texte. Nos marqueurs sont distincts pour le suivi de l'apparence et de la géométrie de l'objet graphique à tracer. Cependant pour le texte, certaines propriétés de style comme font-family (qui modifie la police de caractères utilisée) ou font- style (qui indique si le texte est affiché en gras ou en italique) nécessite effectivement de recalculer la forme géométrique du texte. Ces différents marqueurs pourraient donc être fusionnés.

7.5 Conclusion

Dans le cadre de ces travaux, nous avons réalisé une implémentation logicielle des différents algorithmes présentés dans ce chapitre. Cette implémentation s'intègre dans la plateforme logicielle libre nommée GPAC. Au sein de cette plateforme, nous avons donc développé un module de lecture de fichier SVG ainsi qu'un module de décodage de flux binaire au format LASeR, dont le rôle est de créer les mêmes structures d'arbre de scène que le lecteur de fichiers XML. Cette implémentation a servi, dans le cadre des activités de normalisation SVG et LASeR, à montrer la faisabilité d'une implémentation se basant sur un seul arbre de scène capable de représenter des données issues d'un flux LASeR ou d'un document SVG. La preuve de cette faisabilité a permis au consortium 3GPP de baser sa solution technique pour les scènes multimédia interactives et dynamiques à la fois sur LASeR et sur SVG.

Nous avons également implémenté les modules de composition et de rendu de scènes SVG conformément aux algorithmes présentés précédemment, notamment concernant la gestion des éléments temporels et des éléments graphiques. Nous avons validé la faisabilité d'un lecteur conforme à la norme SVG (avec les limitations présentées précédemment) qui allie la rapidité d'affichage et la faible utilisation mémoire. Nous avons également montré l'impact important sur toutes les parties d'un lecteur SVG dû à l'implémentation conjointe des notions d'héritage et d'animation.

Ce lecteur à l'heure actuelle est conforme à plus de 87% des séquences de conformité SVG Tiny 1.1, le reste étant lié au traitement des polices de caractères au format SVG, que nous n'avons pas étudié. Il a été validé sur PC, PDA et téléphone mobile comme le montre la Figure 7.6. De plus, même si aucune séquence de conformité SVG Tiny 1.2 n'existe au moment où ce document est rédigé, le lecteur

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

- 176 -

permet la lecture synchronisée, conformément à la norme SMIL, de contenu mixte SVG/audio/vidéo. Ces travaux nous ont conduit à soumettre de nombreux commentaires dans le cadre du processus de standardisation SVG notamment sur la consommation mémoire et les interfaces de programmation (voir section 9.5).

Figure 7.6 – Captures d'écran du lecteur SVG du projet GPAC

Enfin, cette implémentation nous a permis notamment de réaliser le parallèle entre les algorithmes de composition de scènes SVG et de scènes BIFS. Nous avons réalisé une implémentation qui, s'appuyant sur des moteurs de composition légèrement différents mais sur un moteur de rendu unique, permet la présentation de scènes SVG et BIFS. En effet, au niveau du module de composition, le traitement des éléments temporels du langage SVG est effectué au même moment que le traitement des nœuds

TimeSensor. Le traitement des évènements peut également être effectué en parallèle dans le modèle VRML et DOM sans effet de bord et la gestion des média fonctionne de façon similaire. Ainsi, nous avons également pu avec succès valider la lecture de contenu multimédia animé interactif mixte BIFS et SVG.