La présente invention se rapporte à un procédé pour construire une image à afficher sur un système d'affichage, tel qu'un écran à partir d'une pluralité d'objets. Un objet est un élément graphique qui peut être affiché à l'écran. Il peut être de type vidéo, bitmap ou vectoriel par exemple. Si l'approche "objet" est une notion répandue au niveau applicatif, les mécanismes d'affichage actuels se contentent traditionnellement d'aller chercher l'image déjà construite quelque part en mémoire, dans une zone prédéfinie qui fait généralement la taille d'une trame vidéo, d'où son nom de "mémoire de trame" ou "frame buffer" en langue anglaise. Entre un module applicatif gérant des objets, et un module d'affichage exploitant une mémoire trame, un module de copie d'objets est communément utilisé permettant de récupérer un objet dans une zone quelconque et de venir l'écrire dans la mémoire trame. Les systèmes graphiques et vidéo selon l'art antérieur utilisent des mémoires de trame dans lesquelles les images sont fabriquées à partir de primitives graphiques et vidéo et d'objets copiés dans ces zones. Lorsqu'il existe plusieurs plans mémoire, ceux-ci sont généralement recombinés au moment de l'affichage en utilisant des mécanismes de multiplexage, d'incrustation ("chroma-keying" en langue anglaise) ou de fusion par transparence ("alpha-blending" en langue anglaise) . Cette approche est très gourmande en espace mémoire, surtout pour les systèmes désireux d'offrir une très bonne qualité visuelle, et qui requièrent alors de multiples plans mémoire. Par ailleurs, à chaque fois qu'un objet graphique est remplacé par un autre, supprimé ou déplacé, il y a reconstruction totale de la mémoire trame dans laquelle il se trouve, d'où une perte en fluidité. Pour les systèmes standards, le dynamisme et la qualité visuelle que l'on veut apporter à une Interface Homme-Machine sont complètement dimensionnant pour le cœur processeur du système (matériel et/ou logiciel, "hardware" et/ou "software" en langue anglaise) et pour la quantité de mémoire. Ainsi : plus le processeur sera puissant, plus il pourra réaliser un grand nombre d'opérations lors de la préparation des plans images et gérer des modifications importantes de contenu d'une trame à la suivante, et plus il pourra manipuler un grand nombre de plans mémoire; plus il y a de plans mémoire, plus le nombre de niveaux graphiques est important, ce qui accroît les possibilités en terme de transparence complexe dans l'image finale. La présente invention vise à remédier aux inconvénients précités en proposant un procédé de construction d'image dans lequel la mémoire utile à cette construction et la puissance utile du système sont réduites par rapport aux systèmes de l'art antérieur. On atteint le but précité avec un procédé pour construire une image apte à être affichée sur un système d'affichage à partir d'une pluralité d'objets. Selon l'invention, pour chaque trame vidéo du système d'affichage, on construit l'image ligne par ligne directement depuis les objets en réalisant les étapes suivantes : - pour chaque ligne du système d'affichage, on construit à la volée cette ligne en récupérant et en stockant, en temps réel, dans au moins une mémoire ligne, tous pixels relatifs aux objets destinés à être affichés sur ladite ligne, et on envoie ces pixels au système d'affichage selon une suite de pixels, de sorte que l'image n'est formée que sur ledit système d'affichage; et en ce que le mécanisme de construction de la ligne est synchronisé en ligne et en trame avec le système d'affichage. Contrairement aux systèmes de l'art antérieur, la présente invention permet d'afficher directement des objets sur un système d'affichage tel qu'un écran. L'objet est au cœur du mécanisme de construction de l'image. On dit que la construction de l'image est volatile puisque son mécanisme n'a pas recours à une mémoire trame et que l'image n'existe nulle par ailleurs que sur le système d'affichage. En d'autres termes, on construit l'image ligne par ligne en temps réel depuis les lieux où sont disséminés les objets jusqu'au système d'affichage. Alors que dans les systèmes de l'art antérieur, on construit d'abord l'image à l'

partir des objets, on stocke cette image dans une mémoire trame, puis on affiche l'image déjà formée. Par système d'affichage, on entend un système comprenant un ou plusieurs écrans synchronisés en ligne et en trame, et pilotés par un contrôleur unique générant des signaux de cadencement des écrans, ce contrôleur étant disposé dans l'accélérateur. Par exemple, du point de vue de l'accélérateur, deux écrans côte à côte peuvent être considérés comme un seul écran de définition double. D'autre part, le système d'affichage peut comprendre une mémoire d'affichage apte à recevoir les pixels formant l'image. L'image est alors formée au sein de cette mémoire d'affichage plutôt que directement sur un écran. Par ailleurs, lorsque les objets graphiques ou vidéo sont stockés en mémoires sous forme compressée, la présente invention présente un avantage certain par rapport aux systèmes standards puisqu'elle nécessite peu de mémoire (absence de mémoire trame), donc un coût de revient inférieur. En outre, puisque l'image est construite directement', opération de préparation de la trame dans une mémoire trame est évitée, d'où une diminution de la bande-passante nécessaire au niveau de la mémoire. Ayant moins d'opérations à effectuer pour afficher une image à l'écran, le système tout entier peut être moins puissant, donc moins consommateur d'énergie, moins perturbant, ce qui est primordial pour un système embarqué par exemple. La présente invention permet donc de réaliser des images d'une très grande qualité visuelle à partir de composants faible puissance. Puisque l'image que voit un observateur n'existe que sur l'écran et n'est pas stockée, l'image doit être reconstruite à chaque nouvelle trame vidéo. En conséquence, la réalisation de séquences d'images complexes avec des objets dynamiques ne nécessite aucune puissance supplémentaire par rapport à ce qui est nécessaire pour afficher toujours la même image. En revanche, les systèmes standards sont rarement capables de mettre du dynamisme dans leur Interface Homme-Machine (IHM) ou bien le font au détriment de l'aspect temps réel puisque le nombre important d'opérations nécessaires à la préparation de l'image dans la mémoire trame peut dépasser la durée de la trame vidéo de l'écran. Pour un coprocesseur graphique standard, l'aspect dynamique d'une image (d'une IHM) est dimensionnant. Avec la présente invention, une image dynamique peut être obtenue sans re-dimensionnement puisque le nombre d'opérations à réaliser dans le temps trame sera le même. On entend par image dynamique, une image composée d'objets 2D pouvant évoluer au fil du temps, se déplacer, se transformer, changer d'état, ... Selon une mode de mise en œuvre avantageux de l'invention, on utilise deux mémoires lignes réalisant, de façon décalée, chacune successivement une étape de construction puis une étape d'affichage de telle sorte que lorsqu'une première mémoire ligne affiche des pixels sur la ligne courante, on construit et stocke dans la seconde mémoire ligne des pixels destinés à être affichés sur la ligne suivante. D'une façon générale, au cours de l'étape de construction de l'image, on réalise les étapes suivantes pour chaque ligne du système d'affichage : on identifie indépendamment chaque objet devant être présent sur cette ligne en fonction d'un ensemble de variables propres à chaque objet; on détecte dans chaque objet ainsi identifié, une zone utile correspondant à la ligne considérée; et on convertit les données brutes issues de ladite zone utile en pixels compatibles avec le format d'affichage. De préférence, au cours de l'étape de détection on accède à la mémoire où sont stockés les objets à partir de mécanismes électroniques et on stocke temporairement les données brutes issues des zones utiles dans des moyens de stockage. Avantageusement, une fois les données brutes converties en pixels, on peut appliquer des transformations et des effets à ces pixels. Ces transformations et effets, qui sont en fait des traitements numériques, peuvent par exemple être un affichage partiel ou "clipping" en langue anglaise, re-dimensionnement ou "resizing" en langue anglaise, transparence, seuillage, anamorphisme, filtres,... L'objet étant au cœur du mécanisme, chaque objet est donc indépendamment paramétrable et on peut changer les paramètres d'un objet sans affecter les autres objets. La réalisation d'une IHM est donc extrêmement simplifiée. Selon l'invention, pour écrire un pixel dans une mémoire ligne, on peut d'abord déterminer la position de ce pixel dans la ligne considérée, puis déterminer en outre la valeur du pixel déjà présent dans cette ligne à la même position. Par ailleurs, lors de l'écriture d'un pixel dans une mémoire ligne, ce pixel étant destiné à s'afficher sur une position donnée sur une ligne du système d'affichage, on peut appliquer un mélangeur entre ce premier pixel et un second pixel actuellement stocké dans la mémoire ligne à ladite même position donnée, le mélangeur étant appliqué de manière proportionnelle au niveau de transparence dudit premier pixel. Selon un mode de mise en œuvre avantageux de l'invention, la trame vidéo comprenant deux zones temporelles distinctes que sont une zone morte verticale, dite "verticale blanking intervalle VBI" en langue anglaise et une zone active verticale, dite "verticale active intervalle VAI" en langue anglaise, correspondant respectivement à l'intervalle entre les deux trames actives et à la durée d'affichage d'une trame active, on réalise les étapes de construction et d'affichage à la volée au cours de chaque zone active verticale, et on réalise, au cours de la zone morte verticale, toute préparation nécessaire au déroulement de la construction. Ladite "préparation nécessaire" peut être toute action de préparation de la trame à venir. Alternativement, on peut réaliser au cours de chaque zone active verticale, toute préparation nécessaire au déroulement de la construction, les étapes de construction et d'affichage à la volée. Dans ce cas, ladite "préparation nécessaire" est de préférence toute action de préparation ou d'anticipation de construction de la ligne à venir. Cette préparation peut comprendre la détermination ou la mise à jour (lorsque les variables sont déjà déterminées) d'un ensemble de variables propres à chaque objet. Ces variables peuvent être extraites de chaque descripteur matériel associé à chaque objet, puis stockées au sein de l'accélérateur. Un descripteur matériel est l'ensemble des paramètres graphiques et d'affichage définissant l'objet correspondant. Les objets peuvent être de natures différentes. On peut avoir des objets vidéo, vectoriels, bitmap, ou autre. Grâce au descripteur, on peut gérer de la même manière des objets hétérogènes. Ladite préparation peut également comprendre un tri des objets par ordre de profondeur par exemple décroissante ou croissante de façon à hiérarchiser l'ordre avec lequel les objets seront superposés à l'écran. On peut réaliser le tri en balayant une première fois tous les objets pour déterminer l'objet le plus enfoui, puis en recommençant le balayage des objets sans tenir compte des objets déjà triés, jusqu'à ce que tous les objets soient triés. Toutefois, le tri peut être fait pendant la construction. Le mécanisme de construction volatile selon l'invention permet de prendre en compte pour chaque objet un niveau de profondeur pour l'affichage final, permettant de simplifier la gestion des recouvrements d'objets et de fenêtres d'un point de vue applicatif, en déléguant au "hardware" ce travail complexe et fastidieux d'un point de vue logiciel. L'invention n'impose pas d'un point de vue théorique un nombre maximal de niveaux gérés. En outre, la présente invention permet de gérer un très grand nombre de couches graphiques sans que ce ne soit ni pénalisant ni dimensionnant, à la fois en terme de ressources "hardware", de puissance CPU, et de quantité de mémoire. On peut donc réaliser aisément des transparences complexes : plusieurs objets transparents les uns au dessus/au dessous des autres. Avantageusement, la construction de l'image est gérée par un accélérateur matériel au moyen de mécanismes électroniques, c'est à dire une gestion matérielle, une gestion électrique par des machines d'états. Cet accélérateur matériel est apte à générer la trame vidéo du système d'affichage. Mais, il peut aussi se synchroniser et se verrouiller sur cette trame vidéo du système d'affichage à partir d'une information de synchronisation fournie par le système d'affichage même. Suivant un autre aspect de l'invention, il est proposé un système pour construire une image apte à être affichée sur un système d'affichage à partir d'une pluralité d'objets notamment stockés en mémoire vive. Selon l'invention, le système comprend une unité de traitement tel qu'un microprocesseur associé à un accélérateur matériel : pour construire l'image, ligne par ligne, directement depuis les objets, en récupérant et en stockant, en temps réel, dans une mémoire ligne, tous les pixels relatifs aux objets destinés à être affichés sur chaque ligne active de chaque trame vidéo du système d'affichage, pour afficher ces pixels en les envoyant au système d'affichage selon une suite de pixels à la fréquence pixel, de sorte que l'image n'est formée que sur ledit système d'affichage, et pour synchroniser le mécanisme de construction de la ligne, en ligne et en trame, avec le système d'affichage. Avantageusement, l'accélérateur matériel comprend les éléments suivants : un gestionnaire d'objets pour activer et caractériser des traitements liés aux objets, une mémoire de stockage des paramètres et variables de chaque objet, - un module matériel de type DMA ("Direct Memory Access" en langue anglaise) contrôlé par l'accélérateur (et non par l'unité de traitement) apte à récupérer des données des objets depuis une mémoire, une mémoire tampon pour stocker temporairement les données provenant du module matériel DMA, un module de décompression et de conversion de données brutes provenant de la mémoire tampon en pixels, un multiplexeur pour sélectionner le pixel à afficher entre celui provenant du module de décompression et de conversion et celui provenant d'une source externe, à la condition que la source externe, l'accélérateur et l'écran soient synchronisés, un mélangeur pour mélanger le pixel provenant du multiplexeur et un pixel actuellement affiché en fonction de la transparence du pixel provenant du multiplexeur, et deux mémoires ligne assurant successivement à tour de rôle l'affichage sur la ligne courante du système d'affichage de pixels préalablement stockés, et le stockage de pixels provenant du mélangeur et qui sera affiché à la ligne suivante. A la façon d'un OSD (On Screen Display) , le présent système comprend des moyens pour insérer/incruster des informations graphiques dans un flux vidéo principal. A la différence de celui-ci, les informations insérées sont des objets hétérogènes et paramétriques. D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée d'un mode de mise en œuvre nullement limitatif, et des dessins annexés, sur lesquels : La figure 1 est une vue schématique simplifiée d'un processus de construction et d'affichage d'une image selon l'art antérieur; - La figure 2 est une vue schématique simplifiée d'un processus de construction et d'affichage d'une image ligne par ligne en temps réel selon la présente invention; La figure 3 est un schéma illustrant deux zones temporelles d'une trame vidéo selon l'invention; - La figure 4 est un schéma illustrant la façon dont deux mémoires ligne sont utilisées pour la construction et l'affichage d'image ligne par ligne selon l'invention; et La figure 5 est une vue schématique simplifiée d'un accélérateur matériel mettant en œuvre le procédé selon la présente invention. Sur la figure 1, on désire réaliser et afficher sur un écran 1 une image à partir d'une pluralité d'objets 2 contenus dans une mémoire vive 3. Pour ce faire, selon l'art antérieur, un module 4 de copie d'objets construit ladite image qui est ensuite stockée dans une mémoire trame 5. Cette dernière fait généralement la taille d'une trame vidéo. Un module d'affichage 6 se contente alors d'aller chercher l'image déjà construite dans la mémoire trame 5 et de l'afficher sur l'écran 1 pendant la durée d'une trame vidéo. La présente invention met en œuvre un procédé complètement différent. Sur la figure 2, on désire également afficher une image sur l'écran 1 à partir d'une pluralité d'objets 2 stockés en mémoire vive 3. Pour ce faire, on utilise un processeur matériel ou "hardware" en langue anglaise, autrement appelé accélérateur matériel graphique, pour construire à la volée et en temps réel ladite image à partir des objets 2. Cet accélérateur, notamment représenté sur la figure 5, réalise différentes opérations au cours de la trame vidéo et les répète à chaque nouvelle trame. Ainsi, durant une trame, pour chaque ligne active de la trame, le système selon l'invention construit en temps réel les pixels devant s'afficher sur cette ligne à partir des objets 2. En d'autres termes, l'accélérateur matériel comprend un module 7 pour construire les pixels d'une ligne courante de l'image à afficher, au moins une mémoire ligne 8 pour stocker temporairement les pixels ainsi construits, et un module d'affichage ligne 9 sur l'écran 1. D'une façon générale, dans la trame vidéo qu'il génère ou sur laquelle il se synchronise et se verrouille, l'accélérateur matériel identifie alors, conformément à la figure 3, deux zones temporelles distinctes qui sont : la zone morte verticale (dite "vertical blanking intervalle", VBI) la zone active verticale (dite "vertical active intervalle", VAI) Le mécanisme de construction volatile selon l'invention s'appuie sur ces intervalles de temps pour réaliser l'affichage d'une image composée d'objets à l'écran et stables le temps d'une trame. Macroscopiquement, on distingue le VBI et le VAI. On profite du VBI de la période trame pour réaliser toute la préparation nécessaire au bon déroulement de la construction volatile qui se déroulera dans le VAI par un processus ligne. Pour chaque ligne active de l'écran, la construction volatile consiste à remplir une mémoire de ligne avec les segments de ligne des objets qui sont actifs dans la ligne considérée. Le contenu de la mémoire de ligne est ensuite envoyé à l'écran au rythme de la fréquence pixel. Comme on le verra ci-dessous avec la figure 4, la présente invention permet à ce que lorsqu'on affiche une ligne (L-I) , pendant ce temps là, la ligne suivante (L) est en cours de construction. Sur la figure 3, la synchro H correspond à la synchronisation ligne (Horizontale) , et la synchro V correspond à la synchronisation trame (Verticale) .

On va maintenant décrire le processus réalisé dans la zone morte verticale VBI pour préparer la construction volatile de la zone active verticale VAI. La première étape peut consister à décoder un descripteur matériel afin d'élaborer des variables qui seront utilisées lors de la construction des lignes pendant la zone VAI. Un descripteur matériel est associé à chaque objet. On entend par "descripteur matériel" un ensemble cohérent de données, créé et initialisé généralement par un processus applicatif. Ce descripteur contient toutes les informations pour que l'accélérateur matériel puisse afficher l'objet qui lui est associé. Ces informations, notamment stockées dans des registres ou mémoires, comportent des paramètres graphiques décrivant la nature de l'objet et des paramètres d'affichage. Ces derniers peuvent être dissociés en paramètres indispensables (position, attributs d'affichage tel que niveau de transparence,...) et paramètres de transformations (affichage partiel ou "clipping", re-dimensionnement ou "resizing", rotation, anamorphisme, filtres,...) . Chaque objet peut être de nature différente en ce qu'il appartient à une classe donnée (vectoriel, vidéo, bitmap, ...) ou comporte une organisation de couleur donnée (mode palette, noir et blanc, couleurs en 16, 24, 32 bits, avec transparence ou non, ...) . Le descripteur peut être local à l'accélérateur matériel ou dans une mémoire externe. Dans ce dernier cas, il convient d'abord de récupérer le descripteur avant d'entamer le décodage. Le décodage du descripteur consiste à en extraire toutes les variables qui vont servir lors de la construction volatile. Le décodage du descripteur sera plus ou moins long, plus ou moins complexe, en fonction des capacités de l'accélérateur matériel à réaliser des fonctions évoluées et complexes (filtres, "resizing", anamorphisme, "clipping", déplacements,...) . Le décodage de certaines informations du descripteur peut même être inutile si les paramètres fournis correspondent déjà aux variables utiles à la construction volatile. Néanmoins, l'idée consiste à déléguer au niveau du matériel, "hardware", le pré¬ traitement des données brutes pour qu'il puisse garantir le temps réel et être synchronisé dans la trame avec la construction volatile. Cela permet aussi de stocker dans le descripteur des paramètres évolués qui seront directement (ou presque) transmis par une application dite API ("Application Program Interface" en langue anglaise) orientée objet. En effet, l'accélérateur matériel est associé à un microprocesseur qui est programmé de manière à offrir un ensemble de fonctions prédéfinies accessibles par l'intermédiaire de cette API. Pour illustrer le rôle du décodage, pour un objet composé par exemple d'une image bitmap stockée quelque part en mémoire. Son descripteur contient alors : l'adresse où commence la donnée image en mémoire; la taille de l'image; la position de l'objet à l'écran; l'organisation de couleur de l'image bitmap telle qu'elle est stockée en mémoire; le niveau de transparence global de l'objet; ... Imaginons que les coordonnées de l'objet soient légèrement négatives par rapport à l'origine de l'écran. Seule la partie visible de l'objet devra être traitée pour être affichée, le reste étant rogné ("clipping") . Cela signifie que la position réelle de l'objet devra être déterminée, que l'adresse de l'objet en mémoire devra être mise à jour pour pointer directement sur le premier pixel visible. La taille du segment de ligne utile à la construction volatile d'une ligne doit aussi être déterminée en fonction du "clipping", mais aussi en fonction de l'organisation de couleur des pixels en mémoire. Ainsi, pour chaque objet, le décodage du descripteur aboutit à une série de variables de travail qui sera exploitée par l'accélérateur matériel lors de la construction volatile. Si les descripteurs peuvent être stockés dans une mémoire externe, les variables utiles seront avantageusement stockées localement à l'accélérateur hardware pour des raisons d'accessibilité. Certaines de ces variables subiront des modifications au fur et à mesure des processus ligne. Par exemple, à la fin du décodage de descripteur, le pointeur d'adresse pointe sur le premier segment de ligne actif de l'objet stocké en mémoire. Mais le pointeur d'adresse devra pointer au fur et à mesure des processus ligne sur les nouveaux segments de ligne actifs. Une seconde étape peut être le tri des objets par ordre de profondeur décroissante. Ce processus permet de hiérarchiser l'ordre avec lequel les objets seront superposés à l'écran. Il prend tout son intérêt lorsque la transparence globale des objets est gérée par l'accélérateur matériel puisqu'il permet alors de restituer fidèlement la transparence complexe entre les objets. Cela signifie qu'un objet A placé derrière un objet B sera vu proportionnellement à la transparence de l'objet B qui se trouve devant lui. Le tri pourra se faire, par exemple, en balayant une première fois tous les objets pour déterminer l'objet le plus enfoui, puis en recommençant le balayage des objets sans tenir compte des objets déjà triés, jusqu'à ce que tous les objets soient triés. A l'issue de ce balayage, chaque objet pourra par exemple contenir dans un de ses registres, l'index de l'objet suivant dans un ordre de profondeur décroissante, afin que le processus ligne de construction de l'image puisse passer simplement d'un objet à un autre, et dans l'ordre exigé par la transparence complexe. La transparence complexe n'est obtenue que par le principe inventif de construction volatile selon l'invention et décrit ci- dessous

On va maintenant décrire le processus réalisé dans la zone active verticale VAI. Le mécanisme de construction volatile d'image est un processus ligne, ce qui veut dire qu'il s'exécute de nouveau pour chaque ligne active de l'écran, c'est-à-dire pour chaque ligne de la VAI (voir figure 3) . Processus ligne : Le mécanisme de construction d'une ligne est synchronisé avec le mécanisme d'affichage qui consiste simplement à envoyer à l'écran une suite de pixels à la fréquence pixel. Pour ce faire, on peut très bien n'utiliser qu'une seule mémoire de ligne pour ces deux mécanismes, sachant que le mécanisme de construction doit alors être temporisé pour ne pas mettre à jour des pixels qui n'ont pas encore été envoyés à l'écran. On peut également utiliser deux ou plusieurs mémoires de ligne. Dans ce cas, certaines dites "off screen" servant à construire les lignes suivantes, pendant que une dite "on screen" est envoyée à l'écran pour remplir la ligne courante. A la fréquence ligne, par exemple au moment du top de synchro ligne, les processus sont inversés. La mémoire "off screen" devient la mémoire "on screen" et vice et versa. La figure 4 illustre ce mécanisme sur deux lignes successives Ligne n et Ligne n+1 où l'on remarque l'inversion des rôles entre les deux mémoires 10 et 11. Construction de la ligne : Pour une ligne de l'écran donnée, il s'agit de récupérer tous les segments des objets qui doivent se trouver dans cette ligne. Pour savoir si un objet se trouve dans la ligne, on exécute un processus permettant successivement pour chaque objet d'identifier si oui ou non l'objet est présent dans la ligne d'écran considéré. Le fait qu'un objet soit présent ou non dans une ligne de l'écran dépend de plusieurs paramètres qui sont propres à chaque objet. Dans le cas d'un objet bitmap rectangulaire stocké comme tel et affiché comme tel, on peut citer : la hauteur de l'objet (en nombre de pixels); la coordonnée "y" de l'objet (en nombre de pixels par rapport à une origine conventionnelle) . Si l'objet est affecté d'une zone de "clipping", on tiendra compte également des paramètres de cette zone. Si l'objet doit subir un "resizing" vertical, on tiendra compte de la taille finale de l'objet, c'est-à-dire à l'écran, pour déterminer si un morceau de cet objet se trouve dans la ligne d'écran considérée. Lorsque l'on sait qu'un objet est présent dans la ligne active, il faut encore déterminer quelle est la zone utile de cet objet dans la ligne considérée, savoir où et comment récupérer cette zone, et savoir à quel endroit la placer dans la mémoire de ligne. Par exemple, dans le cas d'un objet bitmap rectangulaire stocké en mémoire et affiché anamorphose à l'écran, la récupération du segment utile oblige entre autre à déterminer : l'adresse mémoire où se trouve le premier pixel du segment d'objet; - le nombre de pixels contenu dans le segment de l'objet; la loi de variation horizontale et verticale entre deux pixels . La détermination de ces variables ne suffit pas à récupérer le segment utile de l'objet. Il faut également considérer les paramètres objet suivants : la largeur de l'objet stocké en mémoire (en octets); l'organisation de couleur des pixels; la loi de compression, si l'objet est stocké de façon compressée. Du point de vue des actions à effectuer : on exécute un processus permettant successivement pour chaque objet : a) de calculer les variables nécessaires à la récupération du segment utile; b) de récupérer les paramètres objet nécessaires; c) de mettre à jour les variables dans les registres en anticipation des prochaines lignes, par exemple le pointeur d'adresse mémoire. On exécute également un processus permettant d'accéder à la mémoire où sont stockés les objets, à partir de commandes matérielles. On peut par exemple parler de "DMA hardware", pour "Direct Memory Access" en langue anglaise, géré par l'accélérateur matériel, par comparaison avec un DMA traditionnellement géré par un microprocesseur. On exécute aussi un processus permettant de commander et de surveiller le DMA. Le mécanisme "hardware" de construction volatile selon l'invention peut avantageusement être implémenté dans un FPGA qui permet d'intégrer la totalité des modules et processus nécessaires à la mise en œuvre du procédé selon l'invention. Sur la figure 5, on voit la manière dont un accélérateur matériel 21 peut être architecture sur un tel FPGA. Pour le stockage des objets graphiques, on utilise avantageusement une mémoire 20 (SDRAM, DDRAM...) dont la bande- passante est suffisamment importante pour permettre au mécanisme de construction volatile de récupérer suffisamment d'informations (données utiles des objets actifs) lors du processus ligne. Cette mémoire 20 est une mémoire vive externe à l'accélérateur 21. Sur la figure 5, on distingue : a) Un gestionnaire d'objet 14 réalisant l'activation et la caractérisation des traitements propres à l'objet t (intra-objet) ainsi que la gestion entre les objets (inter-objets) . b) Un registre 15 de stockage des paramètres et variables de travail pour chaque objet. c) Un module "DMA hardware" 12 contrôlé par le gestionnaire d'objet 14 et capable d'aller rechercher les données (par exemple des images bitmap) dans la mémoire externe 20. d) Une mémoire tampon 13 pour stocker temporairement les données brutes en provenance du DMA 12, lorsque les processus DMA et un pipeline 16 de décompression/conversion ne sont pas synchronisés. e) Deux mémoires de ligne 19 ou "une buffers" en langue anglaise, (l'une "off screen" et l'autre "on screen" conformément à la figure 4. f) Le pipeline 16 de décompression/conversion des données brutes en pixels. Plus précisément, Une fois que le segment d'objet est récupéré par le DMA, il s'agit de convertir les données brutes issues du DMA en pixels dans le format de sortie retenu pour pouvoir être stockés dans la mémoire de ligne. Dans le cas d'un objet de type image bitmap, cela nécessite de connaître : l'organisation de couleur des pixels; la loi de variation horizontale entre deux pixels; et - la loi de compression, si l'image est stockée de façon compressée. Ce pipeline comprend également des moyens pour transformer les pixels. Une fois les données brutes converties en pixels, il est possible d'appliquer des traitements numériques, tels que par exemple des filtres ou des effets sur ces pixels. On peut par exemple citer : "chroma-keying" : le pixel devient transparent si sa valeur est égale à une valeur de référence qu'on appelle la valeur de "chroma-key"; - seuillage par luminance : le pixel devient transparent si la valeur de son niveau de luminance est inférieure à une valeur de référence qu'on appelle valeur de seuil; seuillage par chrominance; niveau de transparence : on modifie le niveau de transparence du pixel dit "alpha" en appliquant la formule alpha_pixel = alpha_global_objet x alpha_pixel_source; filtres de couleur : modification de la chrominance du pixel; filtres passe-bas, passe-haut : influence des pixels voisins au pixel courant par un pipeline adapté; - Etc. g) Un mélangeur de pixel 18 ("blending") suivant la transparence du pixel considéré. L'écriture des pixels en mémoire ligne représente la dernière étape dans le processus ligne de la construction volatile. L'écriture d'un pixel dans la mémoire nécessite de connaître : la position du pixel dans la ligne : coordonnée "x" par rapport à l'origine égale au premier pixel de l'écran; et - la valeur du pixel déjà présent dans la ligne à la même position, en particulier lorsque l'objet est semi-transparent. h) Un multiplexeur 17 sélectionne soit le pixel issu du flux vidéo principal (vidéo_in) , soit le pixel issu du flux provenant du DMΔ 12. Ce mécanisme impose que le cadencement de l'accélérateur soit synchronisé et verrouillé sur la source vidéo. La fréquence de fonctionnement du pipeline est égale à plusieurs fois la fréquence pixel de l'écran, et le multiplexeur sélectionne le pixel vidéo à la cadence d'une fois par période pixel (à la fréquence pixel) . Le reste du temps, le multiplexeur gère le flux issu du DMA 12. Lorsqu'il n'y a pas de flux vidéo principal, celui-ci est remplacé par une couleur de fond ("background") . Cet exemple d'architecture permet aussi de réaliser une fusion de la vidéo avec la couleur de fond proportionnellement à un niveau de transparence vidéo ( alpha_vidéo_in) sans implémenter un deuxième module de fusion.

Ainsi, le procédé de construction d'image selon l'invention rend possible la gestion de niveau de profondeur entre objets graphiques et vidéo sans limite du nombre maximal de couches. Ce nombre de couches n'est pas dimensionnant au niveau des ressources matérielles de l'accélérateur. Ce procédé rend également possible une gestion de la transparence entre les objets graphiques et vidéo en fonction du positionnement des objets sur l'axe des z quel que soit le nombre de couches graphiques qui n'est pas dimensionnant pour obtenir la transparence complexe globale.

Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.