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.
|
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.
|
À 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.
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.
stuf