A.1 Structure générale et architecture d'implémentation

Nous avons exposé et justifié dans la section 4.4 notre choix de construire une cascade de filtres pour rendre les traitements du dessin modulaires et évolutifs. Dès lors, nous avons utilisé ICON pour construire des dispositifs de traitement offrant à la fois la modularité et la flexibilité voulue, mais intégrant de plus ces filtres à la description de l'interaction. Cette intégration offre des possibilités de configuration avancée et d'adaptabilité de l'interaction aux résultats des traitements. Par contre, elle a nécessité une implémentation particulière pour que justement ces traitements ne pénalisent pas l'interaction.

En effet, les dispositifs standards d'ICON répondent à une logique de flot de données où les valeurs émises en sortie dépendent de celles reçues en entrée. Les dispositifs sont donc synchrones, ils reçoivent des valeurs, les traitent et émettent alors les sorties correspondantes. C'est pourquoi, afin de ne pas ralentir l'exécution de la configuration d'entrée et donc pénaliser l'interaction temps réel, il est nécessaire que les dispositifs respectent l'hypothèse réactive en n'effectuant pas de traitements trop lourd (supposant alors un temps de traitement nul). Or, les traitements que nous proposons sur les traits du dessin, bien qu'optimisés pour une utilisation temps réel, ne garantissent pas toujours un temps d'exécution assez rapide pour éviter un blocage de l'interaction. C'est pourquoi nous avons externalisé ces traitements dans des processus indépendants, liés à la configuration d'entrée par des dispositifs asynchrones.

A.1.1 Dispositifs asynchrones

Les dispositifs asynchrones d'ICON sont des dispositifs dont les sorties ne dépendent pas uniquement des entrés reçues. Ils peuvent donc émettre des valeurs de sortie même lorsqu'ils n'ont pas reçu de valeur d'entrée, ou bien des sorties qui ne dépendent pas uniquement de valeurs d'entrée (l'environnement extérieur à la configuration d'entrée). Par exemple, les dispositifs systèmes qui gèrent les périphériques d'entrée sont des dispositifs asynchrones. Ils sont liés à l'environnement et émettent des valeurs lorsqu'ils reçoivent des données de celui-ci. Pour cela, ICON fournit un mécanisme d'entrées/sorties implicites associé à des principes de mise à jour spécifique des dispositifs (voir figure A.1).

Figure A.1: Les dispositifs asynchrones utilisent le mécanisme des entrées/sorties implicites pour communiquer avec l'environnement extérieur à la configuration d'entrée. Ils peuvent émettre des sorties même s'ils n'ont pas reçu de nouvelles valeurs en entrée.

C'est ce type de dispositifs que nous avons utilisés pour réaliser les filtres de traitements du dessin. Ainsi, ils se contentent de recevoir les données à traiter en entrée (les traits, points ou segments) et de les envoyer à l'environnement. Dans le même temps, ils émettent les éventuelles données reçues de cet environnement. Ainsi, ils ne réalisent pas eux-mêmes les opérations de traitement, garantissant un temps d'exécution adapté à l'hypothèse réactive.

A.1.2 Processus légers (threads)

Dés lors, chacun de ces dispositifs asynchrones de traitement du dessin est lié à un processus fils indépendant dans l'environnement d'exécution. Pour un dispositif, son processus léger (ou thread) réalise le traitement voulu en parallèle à l'exécution de la configuration d'entrée (voir figure A.2). De plus, pour la gestion des retours graphiques ou pour des traitements nécessitant une coopération (tels que la fusion des points et des segments, par exemple), les processus peuvent communiquer entre eux par l'intermédiaire d'un processus superviseur.

Figure A.2: Chaque dispositif de traitement du dessin est lié à un thread de l'environnement d'exécution. Il lui envoie les données reçues en entrée et émet en sortie ses résultats. Les threads peuvent aussi communiquer entre eux par l'intermédiaire d'un superviseur.

À chaque pas d'exécution de la configuration d'entrée, les dispositifs envoient leurs éventuelles données reçues en entrée à leur processus associé (l'algorithme de traitement). Dans le même temps, ils émettent les éventuelles données de sortie (résultats du traitement) fournies par ce processus. Ainsi, l'émission de valeurs de sortie n'est pas bloquée par des traitements trop longs et coûteux et ne rallonge pas la durée d'exécution globale d'un « tick» de la machine réactive. Par contre, il est nécessaire d'évoquer les conséquences possibles d'une telle architecture pouvant induire en particulier des décalages dans le traitement des données.

A.1.3 Conséquences sur les traitements

En effet, cette externalisation des traitements des dispositifs implique que leurs valeurs de sortie (les résultats du traitement d'un trait) ne sont pas forcément émises dans le même pas d'exécution que celui où les entrées (le trait) sont reçues^A.1. Cette conséquence de l'architecture proposée pourrait provoquer des «retards» dans le traitement des traits par rapport au moment où ils ont été tracés. De tels retards, si ils prenaient trop d'ampleur, pourraient s'avérer pénalisants, en particulier pour un filtre tel que la détection des phases de dessin qui peut être utilisé pour adapter l'interaction. Par exemple, un changement automatique d'outil basé sur cette détection pourrait intervenir trop tard par rapport à l'état courant du dessin.
Nous ne pouvons actuellement apporter qu'une réponse pratique à ce problème, basée sur les précautions que nous avons prises pour le minimiser et sur notre expérience d'utilisation du système. En effet, nos observations sur son comportement, sur les filtres réalisés et sur l'environnement d'exécution d'ICON nous permettent à l'heure actuelle d'éviter de tels dysfonctionnement.

Tout d'abord, nous avons minimisé un éventuel décalage dans les traitements en conservant le trait comme donnée propagée entre les dispositifs de traitement. En effet, l'opération de segmentation peut décomposer un trait en plusieurs segments. Dès lors, si elle émettait des segments en sortie, elle provoquerait leur accumulation, et des segments issus d'un même trait seraient émis à des moments différents. Pour éviter ce problème, nous avons utilisé une seule donnée de propagation à travers les filtres de traitement: une structure de donnée de trait évoluée, contenant les informations de chaque traitement (segmentation, contexte, etc.). Ainsi, aucun décalage n'est induit si un trait comporte plusieurs segments.

Ensuite, la fréquence moyenne d'exécution d'une configuration d'entrée est de 60Hz, c'est à dire d'un pas toutes les 16,7ms. Cette valeur est largement inférieure à la durée de dessin d'un trait, même les plus rapides, ce qui implique que plusieurs pas sont franchis pendant qu'un trait est tracé. De plus, les traitements que nous avons proposés sont pour la pluspart de complexité linéaire et de temps moyen d'exécution assez faible pour produire un résultat en ne laissant passer que peu de pas. Nous avons alors constaté que les traitements sur les traits déjà dessinés étaient achevés avant la fin d'un nouveau trait.
Il convient toutefois de garder à l'esprit que cette affirmation est expérimentale, basée sur l'observation et que ce comportement devra être étudié plus en profondeur pour des traitements plus coûteux en temps.