Outre le fait que l'on n'ait pas utilisé de script dans cette version mais des nœuds BIFS du type
Conditional, on remarque qu'il existe autant de routes pour la propagation directe de l'évènement que d'écouteurs créés dans la scène SVG. Cependant, pour la propagation ascendante, des routes supplémentaires sont nécessaires. Dans ce cas, il en faut N×(N-1), où N représente la profondeur de l'arbre de scène, ici 3. A partir de cet exemple, on se rend compte, qu'il est possible de représenter le mécanisme de propagation ascendante du modèle DOM Events à l'aide de routes dans le modèle VRML, mais avec la difficulté liée au nombre de routes. Une remarque similaire peut être faite pour la propagation descendante. On peut aussi noter la difficulté de représenter de manière souple la possibilité du modèle DOM Events d'annuler la propagation d'un évènement.
4.2.3 Cascade d’évènements et gestion temporelle
Dans les descriptions de scènes complexes, un évènement déclenche de nombreuses modifications de la scène. En fonction de l'action utilisateur, il faut effectuer des traitements, par exemple en utilisant une fonction script ou un nœud du type Conditional, pour appliquer les modifications sur la scène. Le résultat de ces traitements peut déclencher d'autres évènements. Pour caractériser la multiplication des évènements successifs, consécutifs à une seule action de l'utilisateur, on parle d’une cascade d’évènements primaires, secondaires … en fonction du niveau de l'évènement dans la cascade.
La façon de traiter cette cascade dans une implémentation peut avoir un impact important sur la scène en termes d'aspect visuel ou de performance. Si cette cascade d’évènements primaires, secondaires, tertiaires … est traitée de manière atomique, c'est-à-dire si tous les évènements de la cascade sont traités avant de produire un nouvel affichage de la scène, les conséquences de l'action utilisateur pourront nécessiter un temps important pour être visualisées par l'utilisateur. A l'inverse, si un nouvel affichage est produit avant le traitement complet de la cascade, le résultat de l'action utilisateur sera perçu progressivement comme une série de modifications de la scène appliquées à différents instants dans le temps. Cette seconde approche peut être problématique si l'utilisateur interagit à nouveau avec la scène alors que toutes les conséquences de l'interaction précédente ne sont pas appliquées. Le traitement atomique est l'option généralement choisie par la plupart des implémentations actuelles.
Descriptions de scènes multimédia : représentations et optimisations
- 88 -
De même, la gestion de la cascade d'évènements impose des contraintes sur l’exécution des scripts ou de nœud Conditional. En effet, un script (ou un nœud Conditional) comporte souvent plusieurs modifications de la scène (ajout d'un élément, modification d'attributs …). Il existe deux méthodes pour les appliquer et déclencher les évènements suivants dans la cascade : soit les évènements liés à une modification de la scène sont générés immédiatement après la modification, soit ils sont générés à la fin de l’exécution du script ou du nœud Conditional. Le choix d’une méthode ou d’une autre pourra ne pas produire le même résultat. En général, les langages rencontrés utilisent globalement la première méthode, car la seconde méthode nécessite d'empiler les évènements pendant l'exécution du script.
Un second problème du traitement de cette cascade est lié à l’ordre dans lequel sont traités les évènements secondaires. Supposons qu’un évènement primaire entraîne la création de deux évènements secondaires. Dans quel ordre traiter ces nouveaux évènements ? Doit-on traiter tous les évènements secondaires avant les évènements tertiaires ou doit-on traiter un évènement tertiaire, conséquence d’un évènement secondaire, avant les autres évènements secondaires ? Autrement dit, si on construit un arbre des évènements, doit-on faire un parcours en profondeur ou un parcours en largeur ? A nouveau, le choix de ce parcours pourra produire des résultats différents. Le langage VRML a fait le choix d'un parcours en largeur. Le modèle DOM Events utilise un parcours en profondeur.
Figure 4.6 – Boucle d'évènement
Un troisième problème qu’il faut traiter dans le modèle évènementiel, lié à la présence d’évènements secondaires, est la gestion des boucles, comme l'illustre la Figure 4.6. En effet, un évènement E1 pouvant déclencher un autre évènement E2, il est possible qu'E2 déclenche à son tour un évènement E3 du même type que l’évènement E1, avec les mêmes conséquences. Cela crée une boucle. La méthode utilisée dans le modèle VRML ou le modèle DOM pour casser ces boucles est d’associer à chaque évènement un temps correspondant au cycle de composition dans lequel l’évènement a été généré. Chaque nœud conserve la date du dernier évènement qu’il a traité et s’il reçoit un nouvel évènement avec la même date, une boucle est détectée et le traitement de ce nouvel évènement est ignoré.
Enfin, un quatrième problème, spécifique aux normes VRML et MPEG-4 BIFS, est le problème dit de « fan-in, fan-out ». Comme un nœud peut générer plusieurs évènements dans un même cycle, l’ordre
Chapitre 4 – Descriptions de scènes et interactivité
dans lequel ces évènements sont générés en sortie de nœud est important. C’est le problème de « fan- out ». De même, comme un même nœud peut recevoir plusieurs évènements dans un même cycle, l'ordre de traitement des évènements en entrée est appelé problème de « fan-in ». La spécification VRML bien qu'elle souligne ces problèmes, ne propose pas de solution.
4.2.4 Modification de la scène
Il existe différentes méthodes pour exprimer les modifications qui doivent être appliquées à une scène à la suite d’un évènement (utilisateur ou non). On peut les classer selon deux catégories :
• les méthodes déclaratives, en utilisant un langage textuel ou binaire pour décrire les modifications à appliquer;
• et les méthodes programmatiques, qui utilisent un langage de script.
L'avantage des méthodes déclaratives réside dans le fait que les comportements peuvent être implémentés nativement et donc plus efficacement. Ainsi, si le traitement est simple, le langage déclaratif sera moins coûteux à effectuer. En revanche, si le traitement nécessite des opérations complexes à décrire dans un langage déclaratif (calcul mathématique par exemple) alors le langage de script sera plus approprié. Parmi les méthodes déclaratives pour modifier une scène, on peut citer le mécanisme de « BIFS Updates » [43] et ou celui décrit dans la spécification « REX Events » [59], présentés au chapitre 2.
Cette méthode de modification peut également bien s'intégrer avec les mécanismes d'interactivité précédemment décrits. En effet, la norme MPEG-4 BIFS permet, grâce à l'utilisation d'un nœud particulier, le nœud Conditional, d'indiquer une série de mises à jour à exécuter quand ce nœud reçoit un évènement booléen vrai sur son entrée activate, ou un évènement faux sur son entrée
reverseActivate.
La plupart des langages de descriptions de scènes comme VRML, BIFS ou SVG offrent les deux possibilités mais la diversité des modifications possibles, sans recourir à un langage de script, est différente, notamment à cause de la manière de décrire les évènements.
Les modifications qui sont appliquées à la scène à la suite d'un évènement peuvent être de deux types :
• Soit elles dépendent uniquement de la présence de l'évènement et la nature exacte de l'évènement n'est pas importante. C'est par exemple le cas si on souhaite déclencher une action sur pression d'une touche, indépendamment de la touche pressée.
• Soit les modifications de la scène utilisent un ou plusieurs paramètres issus de l'évènement, comme, par exemple, le code de la clé appuyé, la position de la souris au moment du clic…
Descriptions de scènes multimédia : représentations et optimisations
- 90 -
La plupart des langages de descriptions de scènes permettent déclarativement le premier type de modifications. Pour le second type, il est intéressant de présenter la différence de méthode pour extraire les paramètres issus d'un évènement, entre les modèles évènementiels VRML et DOM.
Dans le langage VRML, les capteurs d’action utilisateur décomposent une action en un ou plusieurs évènements typés simples et exploitables directement par les autres nœuds. Par exemple, grâce au nœud PlaneSensor2D, il est possible de récupérer le déplacement (x,y) du pointeur de la souris entre la pression du bouton et son relâchement, sans avoir à utiliser un langage de script. Cela permet notamment de déplacer des objets (drag and drop). Le Code 4.7 décrit les différents évènements de sortie du nœud BIFS PlaneSensor2D. L'évènement isActive indique si une opération de déplacement est en cours. Il est utilisé pour déclencher des modifications du premier type. Les évènements trackPoint_changed et translation_changed indiquent respectivement la position courante de la souris et le déplacement de la souris depuis que le bouton de la souris a été enfoncé. Les valeurs de ces évènements sont directement utilisables, par exemple, par un nœud de transformation du type Transform2D. Ainsi, si on déclare une route entre le champ
translation_changed d'un nœud PlaneSensor2D et le champ translation d'un nœud
Transform2D, le contenu graphique de ce dernier sera déplacé entre la pression et le relâchement du bouton de la souris sur les objets voisins du nœud PlaneSensor2D.
eventOut SFBool isActive FALSE
eventOut SFVec2f trackPoint_changed 0 0 eventOut SFVec2f translation_changed 0 0