Rapidité de lecture

Le temps passé à la lecture de la description d'une scène est un facteur à prendre en compte à double titre. Si la lecture du contenu s'effectue par fragment, la phase de lecture fait alors partie intégrante du cycle de composition, il faut que le temps de lecture d'un fragment soit bien inférieur à la durée maximale du cycle (par exemple, 33 ms) pour laisser du temps aux phases de composition et de rendu. Si, en revanche, la lecture du contenu s'effectue en une seule étape, c'est-à-dire entièrement avant la première phase de composition, le temps de lecture ne participe pas au cycle de présentation, mais introduit un délai initial qu'il faut minimiser également.

Le problème de la rapidité de lecture est encore plus crucial quand la scène est exprimée en XML, comme c'est le cas pour de nombreux langages de descriptions de scènes (comme SVG). La lecture de document XML peut en effet être très lente et de nombreux travaux se sont penchés sur ce problème. On peut citer notamment les travaux autour du logiciel XMLScreamer [33] qui est un outil pour générer des lecteurs de document XML rapides. D'autres travaux s'appuient sur les techniques de compression présentées dans les chapitres précédents.

Nous avons souhaité évaluer cette deuxième approche, en particulier sur des scènes au format SVG. Pour cela, nous avons implémenté un lecteur de descriptions de scènes au format SVG capable de lire les données issues d'un fichier SVG (c'est-à-dire XML) et d'un flux binaire au format LASeR. Nous avons basé le lecteur de fichier SVG sur le logiciel LibXML[99]. Ce dernier est utilisé ici dans le but d'avoir une référence en la matière, même s'il ne s'agit pas du lecteur XML le plus rapide, comme les travaux sur XMLScreamer le soulignent.

0 50 100 150 200 250 300 350 400 450 500 0 10000 20000 30000 40000 50000 60000 XML SVGZ LASeR Limite de 33 ms

Figure 7.2 – Temps de chargement (ms) d'un contenu SVG en XML, XML compressé selon l'algorithme ZLIB et en LASeR en fonction de la taille du fichier XML (octets)

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

- 150 -

La Figure 7.2 montre le temps nécessaire à la lecture des descriptions de scènes SVG, issues des séquences de conformité de la norme LASeR, à partir d'un fichier XML, d'un fichier XML compressé selon l'algorithme ZLIB et d'un fichier binaire LASeR, en fonction de la taille du fichier XML. Les temps indiqués, en millisecondes, correspondent au temps de lecture du fichier complet. La lecture consiste à lire les données issues du fichier source et à les interpréter pour créer les objets dans l'arbre de scène. Dans les trois cas, les objets créés en mémoire sont identiques.

La Figure 7.2 illustre trois points :

• Le fait que la lecture de documents binaires est plus rapide que la lecture de documents textuels, et que, bien évidemment, cela s'applique aux descriptions de scènes. Elle montre, en particulier, que la lecture binaire au format LASeR est 5 fois plus rapide que la lecture au format SVG (compressé avec ZLIB ou non).

• Le fait que même dans le cas d'une lecture binaire, il existe néanmoins des contenus pour lesquels le temps de lecture est très proche voire supérieur aux 33 ms nécessaires pour un cycle complet de présentation à 30 Hz.

• Le fait que le temps de lecture/décodage d’une scène complète (cela s'applique également à un fragment de scène) peut-être très variable d’une scène à l’autre. Cela s'explique par le fait que les scènes multimédia utilisées décrivent un nombre d'objets, notamment graphiques, lui- même très variable. Ainsi, le temps de chargement d'une scène peut varier de quelques millisecondes à plusieurs secondes dans le cas de contenus volumineux (comme les contenus cartographiques).

Au vu de ces chiffres, dans une architecture de lecteur multimédia efficace, il est donc nécessaire pour la fluidité de lecture de recourir à un lecteur de descriptions de scènes binaires, surtout pour les descriptions de scènes volumineuses. De plus, nous avons vu dans le chapitre précédent qu'un décodeur de scènes binaires pouvait être réalisé avec une occupation mémoire faible. Cette consommation est notamment faible en comparaison avec la mémoire utilisée pour un lecteur XML, où les noms des éléments doivent être stockés de manière statique dans le lecteur. Ainsi, l'utilisation d'un lecteur de descriptions de scènes binaires est avantageuse à double titre : pour la consommation mémoire et la rapidité de lecture.

Cependant, certains contenus resteront trop volumineux (même compressés) pour être lus dans un temps raisonnable par rapport au cycle de rendu comme on peut le voir également sur la Figure 7.2. Pour qu'un lecteur multimédia puisse lire ces contenus de manière efficace, l'amélioration de la rapidité des algorithmes de lecture n'est pas suffisante. A notre sens, une architecture de diffusion de contenu multimédia, et notamment de contenu graphique vectoriel (cartographie, publicités animées) doit s'appuyer également sur deux points importants :

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

• L'intégration au niveau du lecteur de contenu d'un mode de visualisation progressive, comme nous l'avons décrit dans le chapitre précédent. Cette méthode n'est envisageable que pour des contenus adaptés, c'est-à-dire qui ont été construits pour permettre un affichage progressif cohérent.

• L'utilisation dès la phase de création de contenu, des mécanismes de fragmentation temporelle des contenus, plus précisément l'utilisation de la notion de flux de descriptions de scènes, pour découper la scène volumineuse en entités plus petites dont l'auteur pourra contrôler l'instant d'affichage de façon précise.

Suite à ces recommandations, nous écarterons donc les améliorations au niveau de la rapidité de lecture pour nous concentrer sur l'amélioration de la consommation mémoire.