1 Introduction

La construction d'un tel système de présentation est une opération particulièrement délicate. En effet, la disposition temporelle des objets spécifiée par l'auteur n'est qu'une vue idéale conçue par rapport à une forme du temps absolue. Or, cette vue implique la possibilité de réaliser plusieurs actions en un temps nul (hypothèse de synchronisme des événements [BLA 94]), ce qui n'est pas réaliste sur des plates-formes de traitement séquentiel :

• Les différents traitements des données multimédia, comme la décompression ou les transformations graphiques, nécessitent souvent des ressources système importantes. La charge imposée provoque des déviations temporelles qui restent inévitables dans les systèmes d'exploitation actuels comme UNIX ou Windows [SCH 96]. Ces systèmes n'offrent aucune garantie sur les temps de traitement et, pour cette raison, ils sont qualifiés de best effort : ils font pour le mieux.
• L'accès distant aux documents, rendu nécessaire par le volume très important de données comme la vidéo, l'audio et les images n'est pas instantané. Ce type d'accès fait intervenir un nombre élevé d'opérations d'entrée/sortie et provoque des délais supplémentaires dûs à la latence des réseaux qui s'ajoutent à ceux du système. La progression de la présentation devient donc tributaire du débit du flot de données qui conditionne la durée finale des objets multimédia.

Ce chapitre est organisé en trois parties. La première est dédiée à la présentation de notre approche de conception. Elle présente les principales composantes autour desquelles est structuré notre système de présentation. La deuxième partie présente la mise en oeuvre de ces composantes : l'ordonnancement temporel d'une présentation, les mécanismes de synchronisation qui ont été développés (section 3) et le gestionnaire de présentation réalisé pour la restitution d'une présentation (section 4). La dernière partie tire un premier bilan de l'utilisation du système.

[Table des matières]

2 Architecture du système de présentation

La présentation d'un document résulte de la combinaison de traitements réalisés à partir de l'arbre abstrait et du graphe d'exécution. Ces traitements permettent la présentation du document. Il s'agit principalement d'assurer les fonctions suivantes :

• La gestion de la synchronisation temporelle intra- et inter-objets et la prise en compte de l'indéterminisme.
• La gestion des interactions avec l'utilisateur.
• L'accès aux données multimédia sur le disque ou sur un serveur distant.
• La gestion de l'exécution d'une présentation.
• La gestion de la restitution sur les périphériques de la machine.

[Table des matières]

2.1 Organisation du système

L'interface de présentation (GUI)

L'interface de présentation regroupe les moyens de visualisation et d'interaction offerts à l'utilisateur par l'intermédiaire de l'interface graphique. Elle lui permet, d'une part, d'agir dynamiquement au cours de la présentation à travers l'activation de liens ou de boutons d'interactions, et d'autre part, de contrôler la progression temporelle. Cette partie a été décrite dans la section IV.2.5.

L'ordonnanceur

L'ordonnanceur se situe au coeur du système de présentation multimédia. Après le chargement d'un document et la production du graphe d'exécution, le démarrage effectif est pris en charge par l'ordonnanceur. C'est ce module qui coordonne les différentes activités de présentation du document et assure sa progression temporelle. Cette progression est réalisée par une horloge associée au document. L'horloge produit et reçoit les différents événements de présentation en s'appuyant sur deux représentations du temps :

• Le temps relatif au document et aux différents objets décrits par le graphe d'exécution.
• Le temps physique mesuré par rapport à l'horloge de la machine (le temps « réel »).

Chaque événement de l'horloge peut déclencher de nouvelles activités de présentation ou l'arrêt de celles qui sont en cours. Le rôle de l'ordonnanceur consiste à accorder dynamiquement ces deux formes de temps : c'est la supervision de la présentation.

Le gestionnaire de présentation

Le gestionnaire de présentation met en correspondance la progression temporelle du document et les opérations qui permettent de restituer son contenu à l'utilisateur. Alors qu'au niveau de l'ordonnanceur la progression temporelle est simplement perçue à travers des horloges (démarrage, terminaison, etc.), au niveau du gestionnaire elle correspond à des traitements spécifiques sur les média de base (affichage d'une image, animation d'un texte, etc.). Le gestionnaire de présentation permet aussi l'allocation des ressources comme les accès aux données, les entités d'exécution du système et les ressources graphiques et audio. Il est conçu de façon à renforcer l'indépendance de Madeus vis-à-vis de toute plate-forme spécifique.

2.2 Déroulement d'une présentation

Flots de données

Ces flots représentent des données qui circulent au niveau du gestionnaire de présentation. Ils sont de deux types :

• les flots entrants qui concernent les données acquises localement sur disque ou de façon distante à travers le réseau (voir le médiateur d'accès dans la Fig 0 ),
• Les flots sortants qui concernent les données restituées sur les périphériques de sortie de la machine (écran, haut-parleur).

Flots de contrôle

Ces flots sont représentés au sein de l'application par un ensemble d'événements. Ces événements sont de trois types :

• Les événements d'interaction avec l'utilisateur. Ils concernent l'activation de boutons ou de liens hypermédia.
• Les événements de présentation. Ils concernent l'activation et la terminaison d'objets multimédia.
• Les événements de contrôle de la progression temporelle du document. Ils concernent, par exemple, l'arrêt de la présentation ou son redémarrage (Temporal Access Control)[LIT 93].

[Table des matières]

3 Ordonnancement d'une présentation dans Madeus

• La gestion des contextes de présentation permet de maintenir, à chaque instant, l'état courant de la présentation d'un document : objets en cours, valeurs des attributs dynamiques, temps écoulé depuis le début de la présentation d'un objet ou depuis le début du document, etc. (cf. section 3.1).
• La synchronisation inter-objets permet d'une part de gérer l'enchaînement des événements de présentation, et d'autre part d'ajuster le graphe d'exécution pour prendre en compte l'indéterminisme (cf. section 3.2).
• La synchronisation intra-objets permet de cadencer la présentation au moyen des événements de contrôle (TAC) à travers des horloges (cf. section 3.3).
• La gestion de la navigation met en oeuvre la navigation au moyen des liens hypermédia temporisés et gère l'historique. La navigation nécessite des traitements qui portent sur la totalité d'un document (cf. section 3.4).

[Table des matières]

3.1 Contexte d'une présentation

On définit sous le terme de coupure temporelle l'image de la présentation à un instant donné. Elle correspond à l'état d'avancement de tous les objets à cet instant. À partir du graphe d'exécution, on peut déterminer une coupure temporelle pour chaque instant de début ou de fin d'un objet (voir la Fig 1 ). Ces coupures sont utilisées pour la reconstitution du contexte de la présentation lors de la navigation hypermédia (changements de contexte).

Ainsi, à chaque objet du document, qu'il soit composé ou de base, est associé un contexte permettant d'indiquer l'état de sa présentation. Cet état est défini par les informations suivantes :

• Une horloge qui mesure sa progression temporelle. Ces horloges sont calculées par rapport aux horloges des objets englobants selon la structure logique et par rapport à celle de la machine.
• Des pointeurs vers les noeuds du graphe qui correspondent aux instants de début et de fin de l'objet. À partir de ces pointeurs, l'ordonnanceur peut retrouver les actions de synchronisation à effectuer lors de la terminaison de chaque objet.
• Un ensemble d'attributs de présentation, comme la taille, la position géométrique, les attributs dynamiques, etc.

Les valeurs des attributs de présentation sont également mises à jour dynamiquement. Ce processus de mise à jour permet d'assurer la transmission des différents attributs entre les objets composés, ainsi que l'application des attributs de style au niveau des objets de base (mouvement de fenêtre).

Par ailleurs, le contexte de présentation est la structure de base utilisée pour la synchronisation inter- et intra-objets.

[Table des matières]

3.2 Synchronisation inter-objets

• La terminaison d'un objet contrôlable : l'occurrence de cet événement entraîne soit la terminaison, soit l'activation d'autres objets. Ce traitement est réalisé par l'algorithme de synchronisation décrit ci-dessous (section 3.2.2).
• La terminaison d'un objet incontrôlable : l'occurrence de cet événement nécessite, dans un premier temps, d'adapter le graphe d'exécution à partir de la durée observée de l'objet. Ce traitement est réalisé par l'algorithme de formatage dynamique présenté section 3.2.3. Suite à cette opération, il est également nécessaire de gérer la terminaison ou l'activation d'autres objets. Cela revient à appliquer l'algorithme de synchronisation.

3.2.1 Structures de synchronisation

La structure d'un noeud est décrite dans la Fig 3 . Elle comprend les informations suivantes :

• Le nombre d'arcs entrants dans le noeud.
• Le nombre d'arcs sortants du noeud.
• Un compteur de synchronisation (Terminaisons_Restantes) qui reflète, à chaque instant de la présentation, le nombre d'arcs entrants ayant terminé leur présentation. Ce compteur est initialisé au chargement du document et à chaque fois que le noeud est franchi.

• Table d'égalité : cette table contient des paires de liens vers les instants de début ou de fin d'objets qui doivent coïncider temporellement.
• Table de causalité : cette table contient des règles de causalité décrites par des paires d'instants de fin d'objets (e1, e2). Chaque entrée de la table signifie que l'occurrence de l'événement e1 provoque l'événement e2.

Chaque action est composée d'un opérateur spatial décrivant la nature de l'opération à effectuer et d'un opérande.

L'opérande est une référence interne à un objet simple ou composé. Parmi ces opérations, on trouve les actions Map et Unmap permettant de réaliser l'apparition ou la disparition d'un objet de base ou composé à l'écran. Ces actions sont réalisées dans l'ordre suivant : les actions Unmap d'abord, les actions Map ensuite, car les premières concernent des objets dont la présentation se termine et les secondes les objets dont la présentation commence par rapport à l'instant représenté par le noeud. On libère ainsi les espaces occupés sur l'écran graphique avant de les ré-allouer à d'autres objets. D'autres opérations peuvent être attachées à cette liste d'actions. En particulier, des scripts peuvent être activés au franchissement du noeud permettant ainsi la coordination du système de présentation avec des outils externes.

Le graphe de la Fig 3 représente un seul niveau d'une hiérarchie logique : chaque arc pouvant représenter un objet composé et donc un nouveau graphe de synchronisation (hypergraphe). Ainsi la synchronisation d'un document multimédia revient à la synchronisation de tous les objets qu'il contient.

[Table des matières]

3.2.2 Algorithme de synchronisation

Après cette phase, l'ordonnanceur vérifie la condition de franchissement d'un noeud. Elle correspond à une mise à zéro du compteur Terminaisons_Restantes (ligne 18). Dès qu'un noeud atteint cette valeur, l'ordonnanceur met à jour la liste des chaînes actives du contexte (ligne 19) et démarre les horloges des objets correspondants aux arcs sortant du noeud (lignes 20-22). Cette opération se traduit, au niveau du gestionnaire de présentation, par le lancement des activités de présentation correspondantes.

Algorithme : Ordonnanceur(événement : e)

{

1. si (e.type == Démarrer_Document)

2. Déclencher_Noeud(Document.début);

3. sinon /* traitement de la terminaison d'un objet */

4. si (e.type == Terminaison_Objet) {

5. pour (e.O.fin) {

6. 1) e.O.fin in Table_Causalité(e.O.fin)

7. e.O.fin.Terminaisons_Restantes --;

8. e1 = e;

9. tant que exists(<e1,e2,Vrai> in Table_Causalité(e.O.fin)){

10. Termine(e2.Horloge);

11. e2.O.fin.Terminaisons_Restantes --;

12. <e1,e2,Faux> <== <e1,e2,Vrai>;

13. e1 = e2;

14. }

15. 2) e.O.fin in Table_Égalité(e.O.fin)

16. e.O.fin.Terminaisons_Restantes --;

17. }

18. si (e.O.fin.Terminaisons_Restantes == 0) alors {

19. Mettre_à_jour_Contexte(e.O.fin);

20. pour chaque Action de Table_Actions(e.O.fin)

21. Gestionnaire de Présentation (

22. Table_Actions[i].Opération(Table_Actions[i].Opérande));

23. Déclencher_Noeud(e.O.fin);

24. }

25. }

}

/* Activation des arcs sortants d'un noeud */

Fonction Déclencher_Noeud(Noeud : n) {

Pour i=1 à n.Arcs_Sortants

Démarre_Horloge(n.Objet_Sortant[i]);

}

L'interface entre l'ordonnanceur et le gestionnaire de présentation se fait, soit directement par les appels de fonctions spatio-temporelles (Gestionnaire de Présentation), soit indirectement par la modification des valeurs d'horloges (Termine_Horloge) de l'algorithme. Cette technique de synchronisation vise à séparer les fonctions d'ordonnancement temporel des activités de présentation réalisées par le gestionnaire de présentation.

[Table des matières]

3.2.3 Algorithme de formatage dynamique

Dans Madeus, l'approche qui a été retenue est en accord avec la vérification de la contrôlabilité fournie à l'auteur (phase d'observation et phase de recouvrement). On peut relever deux types d'observations de l'indéterminisme lors d'une présentation :

• Les valeurs effectives des intervalles de type incontrôlable qui sont prises en compte dès la phase d'édition.
• Les exceptions qui correspondent à des déviations temporelles imprévues. Elles représentent les cas d'erreurs.

Algorithme : Formateur_Dynamique(événement : e)

{

1 /* Instantiation d'un intervalle incontrôlable */

2. Indéterminisme=e.O.Horloge.Valeur - e.O.Horloge.Lower_Bound;

3. si e.O.Chaîne.Flex > Indéterminisme

4. Formater_Chaîne (e.O.Chaîne, (-1) * Indéterminisme);

5. sinon

6. /* Compensation sur les chaînes concurrentes */

7. pour toutes les Chaînes actives Ch in Contexte(e.O.englobant)

8. Formater_Chaîne (Ch, Indéterminisme);

}

Fonction : Formater_Chaîne (Chaîne : Ch, Entier : Ind)

{

9. Ch.Flex = Ch.Flex - |Ind|;

10. Pour tout objet O in Ch | Doc.Horloge.Valeur < O.fin

11. si O.type == discret {

12. O.fin = O.fin + Ind;

13. fin de la fonction;

14. } sinon

15. si Doc.Horloge.Valeur < O.début {

16. si O.Flex >= Ind {

17. O.Horloge.Durée = O.Horloge.Durée + Ind;

18. O.Flex = O.Flex - |Ind|;

19. fin de la fonction;

20. }

21. sinon {

22. O.Horloge.Durée = O.Horloge.Durée +

23. Signe(Ind) * O.Flex;

24. Ind = Ind - Signe(Ind) * O.Flex;

25. O.Flex = 0;

26. }

27. }

}

L'algorithme de la Fig 5 met en oeuvre le principe d'observation et de recouvrement des intervalles incontrôlables [LAY 96a]. Lorsque l'événement de fin d'un objet incontrôlable a lieu, le montant d'indéterminisme est d'abord calculé (ligne 2). Ensuite, l'ajustement du graphe est pris en compte prioritairement sur la chaîne de cet intervalle (ligne 4). Si la flexibilité de la chaîne, depuis cet instant jusqu'à sa fin, est suffisante, l'indéterminisme est compensé en effectuant le re-formatage cette chaîne. Cette opération consiste à rétrécir la durée de la chaîne du montant d'indéterminisme observé. Dans le cas contraire (lignes 7 et 8), les chaînes concurrentes sont rallongées afin de permettre à la chaîne en question de rattraper ce délai. Par exemple, dans la Fig 6 , pour l'indéterminisme delta, observé sur l'intervalle x de la chaîne C1, le formatage de la chaîne n'a pu être effectué car sa flexibilité f1 est inférieure à delta. Les chaînes concurrentes C2, C3 et C4 sont alors reformatées pour être rallongées de ce même montant delta.

L'avantage de cette technique est de permettre de ré-aligner temporellement les chaînes les unes par rapport aux autres de façon non bloquante et locale. Ceci est effectué grâce au contexte de présentation qui permet, d'avoir, à tout instant, une vision globale de la progression du document. Il est ainsi possible de respecter les contraintes de coïncidence portées par les noeuds extrémités des chaînes.

Par ailleurs, le principe du formateur dynamique peut être employé pour gérer également les exceptions. Il suffit pour cela d'appliquer l'algorithme afin d'imposer le ré-alignement temporel des chaînes. Dans ce cas, on risque de ne plus respecter, momentanément, une partie des contraintes spécifiées par l'auteur.

[Table des matières]

3.3 Synchronisation intra-objets

1. Offrir à l'utilisateur des fonctionnalités (TAC) de contrôle d'une présentation au moyen des actions Pause, Démarre, Redémarre, etc., fournies par l'interface graphique de Madeus.
2. Propager les tics réguliers de l'horloge au sein du gestionnaire de présentation. Ceci permet d'apparier les horloges avec les actions de présentation correspondantes au niveau de l'implantation des objets de base.

Types d'horloges

• Horloges externes : ces horloges correspondent aux objets dont les actions de présentation internes ne sont pas à la portée de l'ordonnanceur, comme les processus externes et les objets multimédia programmés « applets ». Après leur lancement, ces horloges produisent des événements qui indiquent simplement leur fin ou le dépassement de leur borne de durée maximale (exception). Elles regroupent tous les objets qui sont des sources potentielles d'indéterminisme.
• Horloges internes : ces horloges correspondent aux objets dont la synchronisation interne est entièrement contrôlée par l'ordonnanceur. Ce sont les objets multimédia discrets dont la présentation se traduit, soit par des actions portées par les noeuds du graphe (Map, Unmap), soit par les tics réguliers de l'horloge gérée par l'ordonnanceur (mouvement à l'écran). Parmi ces objets, on trouve les objets de type texte et image fixe.

Opérations sur les horloges

Démarre(Horloge) : démarre l'horloge interne d'un objet multimédia depuis son début.

Pause(Horloge) : suspend l'horloge interne d'un objet.

Redémarre(Horloge) : relance la progression de l'horloge d'un objet qui a été suspendue par Pause.

Change_Vitesse(Horloge, Vitesse) : modifie la cadence d'une horloge.

Termine(Horloge) a pour effet d'interrompre la progression de l'horloge.

Tic_un_Quantum(Horloge) : fait progresser l'horloge d'un quantum de temps (un tic).
Fin(Horloge) : indique si l'horloge a atteint sa durée d'échéance.

Algorithme : Gestion_Horloge(événement : e)

{

1. /* attribution des quantums de temps */

2. si (e.type == Fin_Quantum)

3. pour tout objet O in Document.Context tel que Fin(O.Horloge) == Faux et O.Horloge.interne {

4. Tic_un_Quantum(O.Horloge);

5 si Fin(e.O.Horloge)

6 Ordonnanceur(e);

7 }

8. si (e.type == TAC)

9. e.Opération(Document.Horloge);

10. si exists (O in Document.Context)midFin(O.Horloge) == Faux

11. Système_Arme_Chien_de_Garde(Quantum_Madeus);

}

Enfin, pour les objets ayant des horloges externes correspondant à des intervalles incontrôlables, les opérations liées à la modification de leur vitesse d'horloge n'ont pas de sens. Dans ce cas, l'ordonnanceur ignore simplement ces horloges en prenant en compte leurs dates d'échéance au plus tôt.

[Table des matières]

3.4 Gestion de la navigation

On distingue dans Madeus deux types de liens : les liens d'inclusion et les liens de référence. Le traitement de l'activation d'un lien est effectué en fonction de son type. Ce traitement est réalisé selon le schéma suivant :

1. L'émission d'un événement d'activation de lien au niveau du gestionnaire de présentation. Celui-ci identifie l'objet référencé et demande à l'ordonnanceur d'exécuter la requête d'ouverture du lien.
2. Le traitement de cette requête entraîne soit la libération du contexte courant s'il s'agit d'un lien de référence, soit l'arrêt de la présentation en cours s'il s'agit d'une inclusion avec arrêt (cf. Fig 9 ).
3. Le chargement de l'objet cible de la référence est alors amorcé. Cet objet est ensuite interprété et lancé à partir de son instant de début.

Dans le cas d'une référence de type inclusion, l'appel est assimilé à une intégration d'un nouveau graphe de présentation au sein du document (voir Fig 9 ). Ce graphe est ordonnancé en exclusion mutuelle avec celui du document si l'attribut arrêt est positionné à vrai, en concurrence dans le cas contraire. Dans le premier cas la présentation du document est relancée dès la terminaison de l'inclusion et dans le second cas elle n'est pas affectée.

[Table des matières]

4 Gestionnaire de présentation

• Médiateur d'accès : Il associe à chaque objet de base un flot de données en entrée (cf. 4.3).
• Médiateur d'exécution : Il associe à chaque objet de base un flot d'exécution (cf. 4.4).
• Médiateur de présentation : Il gère les ressources de restitution sur l'écran graphique et le périphérique audio (cf. 4.5).

[Table des matières]

4.1 Automate d'états finis

L'occurrence d'un événement se traduit soit par une transition de l'automate d'un état à un autre, soit par la modification des paramètres internes d'un objet (variables d'état).

Les principales actions modélisant une transition d'état d'un objet sont (voir Fig 10 ) :

• Create : cette transition provoque l'initialisation des structures internes d'un objet et l'allocation de ses ressources de présentation.
• Map/Unmap : ces transitions provoquent respectivement l'affichage et l'effacement d'un objet graphique sur la fenêtre de présentation. Dans le cas des objets de type audio ces transitions sont confondues avec les transitions Start/End.
• Start/Pause/Resume/Kill/End/Restart : ces transitions provoquent respectivement le démarrage, l'arrêt, le redémarrage, la terminaison, la fin normale ou la relance d'un objet.
• Play_One_Step : cette transition provoque l'exécution d'un pas de la présentation d'un objet multimédia. Elle est provoquée par l'appel Tic_un_Quantum de l'ordonnanceur.
• Store/Restore : ces transitions provoquent la libération/ré-allocation des ressources d'un objet. Elles interviennent lors du suivi d'un lien hypermédia.

[Table des matières]

4.2 Configuration des objets multimédia de base

• Les périphériques (graphiques ou audio) auxquels les objets sont liés.
• Les flots de données qui constituent le contenu des objets de base.
• Les traitements associés à chaque objet de base au sein du système de présentation.

Le traitement de chaque objet de base est organisé en trois modules :

• Module source : il lit les données, par l'intermédiaire du médiateur d'accès, et les délivre au module de traitement.
• Module de traitement : il effectue les traitements spécifiques à un objet : la décompression, l'adaptation de la taille de l'image, la segmentation du texte en plusieurs lignes, etc.
• Module destination : il restitue les données produites par le module de traitement sur les périphériques correspondants.

[Table des matières]

4.3 Médiateur d'accès

1. L'ouverture d'une connexion avec un serveur distant et la récupération d'un flot de données (stream).
2. Ce flot de données est ensuite passé au module de traitement.

[Table des matières]

4.4 Médiateur d'exécution

• La liaison : elle associe à chaque objet multimédia de base le module de code qui l'implante.
• L'héritage des attributs de présentation : il assure la propagation des attributs de présentation.
• La gestion des événements : elle consiste à acheminer les événements de présentation entre les entités actives du système.

4.4.1 Opération de liaison

1. Type : est une chaîne de caractères qui indique le type de média de l'objet et son format, par exemple le type audio/mpeg.
2. Identifiant du module de traitement : donne la localisation du code de traitement correspondant, par exemple, le fichier binaire exécutable madeus_mpeg.

Les modules de traitement supportés par l'application sont de trois types : processus externe, librairie dynamique ou librairie native. Chaque module de traitement est spécialisé dans la manipulation d'un média et d'un format particulier. Les modules de traitement implantés couvrent les types de base suivants :

• Un module pour la vidéo aux formats mpeg vidéo niveau 1 et mjpeg. Il est réalisé sous forme d'un processus externe.
• Un module pour l'audio aux formats audio mpeg niveau 1 et AU. Il est réalisé sous forme d'un processus externe.
• Un module pour les images supportant les formats xpm, gif, jpeg et png. Il est réalisé sous forme d'une librairie native.
• Un module pour les images au format cgm. Il est réalisé sous forme d'une librairie dynamique et est chargé à la demande.
• Un module pour le texte qui supporte les fontes de X11 et les couleurs. Il est réalisé sous forme d'une librairie native.

4.4.2 Héritage des attributs de présentation

• Les attributs statiques : ce sont les attributs dont les valeurs sont instantiées à la création d'un objet (transition Create).
• Les attributs dynamiques : ce sont des attributs dont les valeurs évoluent au cours de la présentation. Ils sont calculés à chaque transition (Play_One_Step) déclenchée par l'horloge.

À chaque réception d'une demande de création Create, le médiateur peut calculer les valeurs des attributs d'un objet de deux façons : si les valeurs sont définies de façon spécifique à cet objet, elles sont directement utilisées pour la présentation. Dans le cas contraire, ces valeurs sont d'abord héritées de l'objet englobant.

Pour les objets continus, lors de l'exécution d'un pas de présentation provenant de l'ordonnanceur, les différents attributs sont utilisés par le médiateur audio ou graphique pour définir les nouvelles caractéristiques de sortie des différents objets.

La transmission des valeurs d'attributs entre un objet père et ses fils est effectuée à chaque pas de la présentation. Lorsque l'ordonnanceur appelle la fonction Play_One_Step d'un objet composé (voir Fig 13 ), celui-ci met à jour ses propres valeurs d'attributs. Lorsque l'ordonnanceur appelle la fonction Play_One_Step d'un objet de base, celui-ci prend en compte ces modifications en récupérant les valeurs de l'objet composé englobant. Ceci nous amène à un schéma de propagation continue des attributs organisé en deux étapes (cf. Fig 13 ) :

1. L'objet (de base ou composé) hérite les valeurs des attributs de l'objet parent (ReadAttribute) et met à jour ses propres attributs (SetAttribute).
2. Si l'objet est un type de base, il effectue en plus une opération de présentation élémentaire de sortie (OutPut) comme l'affichage à l'écran. Cette opération prend en compte toutes les mises à jour de ses attributs.

[Table des matières]

4.4.3 Gestion des événements

• Un identifiant symbolique qui correspond à un événement interne d'un objet multimédia (Map, Unmap, Start, etc.).
• Un identifiant de la source de l'événement.

Lorsque l'utilisateur clique sur un objet au moyen de la souris, le médiateur est notifié par une fonction de rappel (callback) qui contient l'identifiant de l'objet ayant émis l'événement. Cet identifiant est obtenu grâce au mécanisme d'abonnement fourni par la boîte à outils X11/Toolkit^note3.

Dans le cas des processus externes, l'isolation^note4 du contexte nécessite la gestion d'une communication bi-directionnelle permanente avec l'ordonnanceur. Cette communication est basée sur des échanges de messages entre le serveur X11, le processus Madeus et les processus externes (cf. Fig 14 ).

[Table des matières]

4.5 Médiateur de présentation

[Table des matières]

4.5.1 Médiateur graphique

Au moment de la création d'un objet, ses informations spatiales sont calculées et stockées dans une structure qui associe à chaque objet graphique une fenêtre d'affichage à l'écran. Cette opération tient compte du style attaché à l'objet comme la fonte pour le texte, la taille des caractères, la couleur de fond, etc.

Le médiateur graphique offre les possibilités suivantes :

• Le positionnement relatif des fenêtres à l'écran et leur déplacement dynamique (voir annotation 1 de la Fig 15 ).
• La gestion de plans graphiques complexes comme les contours non-rectangulaires de fenêtres et les recouvrements (voir annotations 2 et 3 de la Fig 15 ).
• Le rafraîchissement continu de l'écran lors des mouvements de fenêtres.
• La gestion des couleurs qui consiste à attribuer à chaque pixel d'une image, décrit en RGB, la couleur la plus proche dans une palette restreinte à 256 entrées.

[Table des matières]

4.5.2 Médiateur audio

Chaque objet est implanté par un processus externe qui lit un flot compressé de données et délivre au médiateur un flot d'échantillons à travers des tampons. Chacun de ces échantillons est caractérisé par l'encodage du signal (u-law, a-law ou format linéaire), des paramètres de fréquence de saisie (8 Khz, 41 Khz, ...) et le nombre de canaux de sortie (mono, stéréo) [GIB 94].

Le rôle du médiateur audio consiste à traiter ces différents signaux dans le but de réaliser les fonctions suivantes :

• Appliquer les attributs de style audio liés à l'objet sur les échantillons produits S(A), S(B) et S(C). Ces attributs sont liés au volume et à la balance pour les stations disposant de sorties stéréo. Une fois cette opération achevée, le médiateur audio additionne les différents signaux pour produire un seul signal final.
• Adapter l'échantillon final aux paramètres de sortie du périphérique audio (fréquence et nombre de canaux).
• Synchroniser le tampon interne de la carte avec le flot produit par le médiateur. Cette synchronisation est nécessaire car les cartes son disposent d'un tampon interne de taille limitée (quelques Kilo octets). Ce tampon doit être maintenu plein tant qu'il y a des échantillons disponibles en entrée.

[Table des matières]

5 Mise en oeuvre de Madeus

Une telle application regroupe des techniques de programmation très hétérogènes : interface graphique, algorithmes et structures de données complexes, manipulation de données multimédia comme l'audio, la vidéo, les images, le texte et la programmation système et réseau.

L'outil est presque entièrement écrit en langage C et représente, dans sa version actuelle, 48 812 lignes de code, dont 30 157 développées dans le cadre de cette thèse. Une partie du prototype est réalisée avec des librairies du domaine public. Le volume de code par partie du prototype est résumé dans le tableau de la Fig 17 .

Partie du prototype	Langage	Boîte à outils	Développés	Réutilisés
Système d'édition	C	lex + yacc	3 107	-
Gestionnaire temporel	C	-	4 442	-
Ordonnanceur	C	-	3 169	-
Médiateur graphique et Interface utilisateur	C	X11 et Motif	4148	-
Audio	C ++	lib-mpegaudio	2442	4 221
Vidéo	C	lib-mpeg	1822	7 300
Image	C	libjpeg, libpng	5 037	7 131
Texte	C	-	698	-
Gestion d'accès	C	lib-http	1783	-
Gestion des événements	C	socket Unix	3509	-

Ce tableau montre une grande disproportion entre le coût du développement du système de présentation par rapport au gestionnaire temporel et le système d'édition (75 %), ce qui constitue l'une des principales charges de réalisation de cette application. Nous avons cependant cherché à limiter cette charge en réutilisant le plus possible les logiciels disponibles actuellement (colonne de droite du tableau Fig 0 ).

Le développement du système de présentation était néanmoins nécessaire dans la mesure où, sans ce module, nous n'avions pas la possibilité de restituer un document, ni même d'expérimenter l'intégration des fonctions d'édition et de présentation au sein d'un même système, ce qui était l'un des objectifs de cette thèse.

L'interface utilisateur, l'ordonnanceur et le gestionnaire de présentation sont implantés, dans l'espace utilisateur du système. L'exécution des activités parallèles de présentation est réalisée au moyen d'un chien de garde (timer) pour tous les objets multimédia d'un document, à l'exception de la vidéo et de l'audio. Ces derniers sont ordonnancés par un flot d'exécution concurrent et une horloge séparée.

Dans certaines implantations de systèmes multimédia, l'utilisation de processus légers est systématique pour ordonnancer tous les objets d'un document. Ce type de synchronisation, utilisé dans CMIFed [HAR 93b], est pénalisant pour plusieurs raisons. L'emploi des processus légers engendre une dé-synchronisation entre les flots parallèles de présentation à cause du grand nombre d'appels au noyau du système qui en résulte [HÖP 91][AND 91]. Par ailleurs, il est nécessaire d'ajouter, pour chaque processus léger, un niveau supplémentaire de synchronisation inter-objets qui se révèle souvent très coûteux (emploi de sémaphores). Or, dans une présentation multimédia, le quantum de temps alloué aux différents flots de présentation est défini par rapport à des actions de présentation (mouvement d'un graphique à l'écran, affichage d'un objet, etc.) et non pas par rapport à des actions atomiques d'exécution (instruction du processeur).

[Table des matières]

6 Bilan du développement de Madeus

• La généricité : l'ordonnancement des objets par des horloges, et non par des fonctions de manipulation directe des objets, permet de garder un aspect générique à l'ordonnanceur [ROT 96].
• L'adaptabilité : la correspondance entre les horloges des objets de base et leur représentation dans le système d'exploitation (processus, threads, timers) peut être adaptée en fonction du type de l'objet multimédia et de la plate-forme d'exécution.
• La réutilisation du graphe : la correspondance entre les tâches à exécuter et le graphe d'exécution est parfaite. Sa réutilisation pour l'exécution évite d'avoir à reconstituer une structure d'exécution similaire au sein du système hôte. De plus, ce graphe constitue une donnée précieuse (prédiction du futur) qui peut être exploitée pour la gestion des ressources [HAR 93a].
• L'extensibilité du système : le mécanisme d'exécution externe et de chargement dynamique permet l'extensibilité du système vers de nouveaux types d'objets multimédia sans modification de l'application (sans recompilation). Cette technique permet de répondre à la diversité croissante des types d'objets multimédia de base. Elle est, de nos jours, employée de façon courante dans les navigateurs World Wide Web : les plugins [NET 96].

En conclusion, le système Madeus est opérationnel et est actuellement utilisé par un étudiant de DEA, un étudiant en thèse et un ingénieur CNAM qui l'emploient comme plate-forme pour mener des expériences dans le cadre de leurs activités de recherche. Des documents multimédia ont également été élaborés à des fins de démonstration. L'outil a notamment été présenté lors des démonstrations :

• Journées nationales du PRC GDR IA à Grenoble.
• Exposition TEC 96.

7 Conclusion

Notes :

Le mot « type » est pris ici au sens temporel du terme : {référence, inclusion}.
(2)

Dans ce chapitre, nous désignerons par le terme objet les éléments d'un document multimédia manipulés dans le contexte du système de présentation.
(3)

Fonction XtAdd_Call_Back.
(4)

Dans Unix, les processus ne partagent pas le même espace d'adressage