EP1738349B1 - Method and system for volatilely building an image displaceable of a display system from a plurality of objects - Google Patents

Description

The present invention relates to a method for constructing an image to be displayed on a display system, such as a screen from a plurality of objects. An object is a graphic element that can be displayed on the screen. It can be of type video, bitmap or vector for example.

If the "object" approach is a widespread concept at the application level, the current display mechanisms are usually content to look for the image already built somewhere in memory, in a predefined area that is usually the size of a video frame, hence its name "frame memory" or "frame buffer" in English. Between an application module managing objects, and a display module using a frame memory, an object copy module is commonly used to retrieve an object in any area and write it in the frame memory.

Prior art graphics and video systems use frame memories in which images are fabricated from graphics and video primitives and objects copied into these areas. When there are several memory planes, these are generally recombined at the time of display using multiplexing, chroma keying or transparency merging mechanisms (alpha-blending). "in the English language). This approach is very greedy in memory space, especially for systems wishing to offer a very good visual quality, and which then require multiple memory plans. Moreover, each time a graphic object is replaced by another, deleted or moved, there is total reconstruction of the frame memory in which it is located, resulting in a loss of fluidity.

• 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.

For standard systems, the dynamism and the visual quality that one wants to bring to a Human Machine Interface are completely dimensioning for the core processor of the system (hardware and / or software, "hardware" and / or "software" in language English) and for the amount of memory. So :

• the more powerful the processor, the more it will be able to perform a large number of operations during the preparation of the image plans and manage important changes in content from one frame to the next, and the more it can handle a large number of memory planes;
• the more memory layouts, the greater the number of graphic levels, which increases the possibilities in terms of complex transparency in the final image.

The present invention aims to overcome the aforementioned drawbacks by proposing an image construction method in which the memory useful for this construction and the useful power of the system are reduced compared to the systems of the prior art.

The above object is achieved with a method for constructing an image capable of being displayed on a display system from a plurality of objects as defined by claim 1.

Unlike the systems of the prior art, the present invention makes it possible to directly display objects on a display system such as a screen. The object is at the heart of the mechanism of construction of the image. It is said that the construction of the image is volatile since its mechanism does not use a frame memory and that the image exists otherwise only on the display system. In other words, we build the image line by line in real time from the places where the objects are scattered to the display system. Whereas in the systems of the prior art, the image is first constructed From the objects, we store this image in a frame memory, then we display the already formed image.

By display system is meant a system comprising one or more screens synchronized in line and in frame, and controlled by a single controller generating timing signals screens, this controller being disposed in the accelerator. For example, from the accelerator point of view, two side-by-side screens can be considered as a single dual-definition screen.

On the other hand, the display system may include a display memory capable of receiving the pixels forming the image. The image is then formed within this display memory rather than directly on a screen.

Furthermore, when graphic or video objects are stored in memory in compressed form, the present invention has a certain advantage over standard systems since it requires little memory (lack of frame memory), therefore a lower cost.

In addition, since the image is constructed directly, the operation of preparing the frame in a frame memory is avoided, thereby reducing the bandwidth required at the memory. Having fewer operations to perform to display an image on the screen, the entire system can be less powerful, so less energy consuming, less disturbing, which is essential for an embedded system for example. The present invention therefore makes it possible to produce images of very high visual quality from low power components.

Since the image that an observer sees exists only on the screen and is not stored, the image must be reconstructed with each new video frame. As a result, the realization of complex image sequences with dynamic objects requires no additional power compared to what is necessary to always display the same image. On the other hand, the standard systems are rarely able to put dynamism in their Human Machine Interface (HMI) or do it at the expense of the real-time aspect since the large number of operations necessary for the preparation of the image in the frame memory may exceed the duration of the video frame of the screen. For a standard graphics coprocessor, the dynamic aspect of an image (of an HMI) is sizing. With the present invention, a dynamic image can be obtained without resizing since the number of operations to be performed in the frame time will be the same. By dynamic image is meant an image composed of 2D objects that can evolve over time, move, transform, change state, etc. Advantageous modes of implementation are defined by the dependent claims.

According to another aspect of the invention, a system is proposed for constructing an image that can be displayed on a display system from a plurality of objects stored in RAM, as defined by claim 10.

• 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 Accesss") 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.

Advantageously, the hardware accelerator comprises the following elements:

• an object manager to activate and characterize object-related processes,
• a storage memory of the parameters and variables of each object,
• a hardware module of the DMA type ("Direct Memory Accesss") controlled by the accelerator (and not by the processing unit) able to retrieve data from objects from a memory,
• a buffer for temporarily storing data from the DMA hardware module,
• a module for decompressing and converting raw data from the buffer memory into pixels,
• a multiplexer for selecting the pixel to be displayed between the one coming from the decompression and conversion module and that coming from an external source, provided that the external source, the accelerator and the screen are synchronized,
• a mixer for mixing the pixel from the multiplexer and a currently displayed pixel according to the transparency of the pixel from the multiplexer, and
• two line memories successively in turn taking the display on the current line of the previously stored pixel display system, and the storage of pixels from the mixer and which will be displayed on the next line.

In the manner of an On Screen Display (OSD), the present system includes means for inserting / embedding graphics information in a main video stream. Unlike in this one, the inserted informations are heterogeneous and parametric objects.

• 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 oeuvre le procédé selon la présente invention.

Other advantages and features of the invention will appear on examining the detailed description of an embodiment which is in no way limitative, and the appended drawings, in which:

• The figure 1 is a simplified schematic view of a process for constructing and displaying an image according to the prior art;
• The figure 2 is a simplified schematic view of a process for constructing and displaying a line-by-line real-time image according to the present invention;
• The figure 3 is a diagram illustrating two time zones of a video frame according to the invention;
• The figure 4 is a diagram illustrating how two line memories are used for the line-by-line image construction and display according to the invention; and
• The figure 5 is a simplified schematic view of a hardware accelerator implementing the method according to the present invention.

On the figure 1 , it is desired to make and display on a screen 1 an image from a plurality of objects 2 contained in a random access memory 3. To do this, according to the prior art, a module 4 for copying objects constructs said image which is then stored in a frame memory 5. The latter is usually the size of a video frame. A display module 6 then simply fetch the image already built in the frame memory 5 and display it on the screen 1 for the duration of a video frame.

The present invention implements a completely different method. On the figure 2 , it is also desired to display an image on the screen 1 from a plurality of objects 2 stored in RAM 3. To do this, it uses a hardware processor or "hardware" in English, otherwise called hardware graphics accelerator , to build on the fly and in real time said image from the objects 2. This accelerator, in particular represented on the figure 5 , performs various operations during the video frame and repeats them at each new frame. Thus, during a frame, for each active line of the frame, the system according to the invention builds in real time the pixels to be displayed on this line from the objects 2. In other words, the hardware accelerator comprises a module 7 to build the pixels of a current line of the image to be displayed, at least one line memory 8 for temporarily storing the pixels thus constructed, and a line display module 9 on the screen 1.

• la zone morte verticale (dite "vertical blanking interval", VBI)
• la zone active verticale (dite "vertical active interval", VAI)

In a general way, in the video frame that it generates or on which it synchronizes and locks itself, the hardware accelerator then identifies, in accordance with the figure 3 , two distinct time zones that are:

• the vertical dead zone (so-called "vertical blanking interval", VBI)
• the vertical active zone (so-called "vertical active interval", VAI)

The volatile construction mechanism according to a comparative example uses these time intervals to display an image composed of objects on the screen and stable the time of a frame. Macroscopically, we distinguish the VBI and the VAI. We take advantage of the VBI of the frame period to achieve all the preparation necessary for the smooth running of the volatile construction that will take place in the VAI by a line process. For each active line of the screen, the volatile construct consists of filling a line memory with the line segments of the objects that are active in the line in question. The contents of the line memory are then sent to the screen at the rate of the pixel frequency. As we will see below with the figure 4 , the present invention allows that when displaying a line (L-1), during this time, the next line (L) is being built.

On the figure 3 , sync H corresponds to line synchronization (Horizontal), and sync V corresponds to frame synchronization (Vertical).

We will now describe the process carried out in the vertical dead zone VBI to prepare the volatile construction of the vertical active zone VAI. The first step may be to decode a hardware descriptor to develop variables that will be used when building lines during the VAI zone.

A hardware descriptor is associated with each object. The term "hardware descriptor" means a coherent set of data, created and initialized generally by an application process. This descriptor contains all the information for the hardware accelerator to display the object associated with it. This information, in particular stored in registers or memories, includes graphic parameters describing the nature of the object and the display parameters. These can be separated into essential parameters (position, display attributes such as transparency level, ...) and transformation parameters (partial display or "clipping", resizing or "resizing", rotation, anamorphism, filters ...). Each object can be of different nature in that it belongs to a given class (vector, video, bitmap, ...) or has a given color organization (palette mode, black and white, colors in 16, 24, 32 bits, with transparency or not, ...).

The descriptor can be local to the hardware accelerator or to an external memory. In the latter case, it is first necessary to recover the descriptor before starting the decoding.

The decoding of the descriptor consists of extracting all the variables that will be used during the volatile construction. The decoding of the descriptor will be more or less long, more or less complex, depending on the capabilities of the hardware accelerator to perform advanced and complex functions (filters, "resizing", anamorphism, "clipping", displacements, ...) . The decoding of certain descriptor information may even be useless if the parameters provided already correspond to the variables useful for the volatile construction. Nevertheless, the idea is to delegate at the hardware level, "hardware", the pretreatment of the raw data so that it can guarantee the real time and be synchronized in the frame with the volatile construction. It also allows to store in the descriptor advanced parameters that will be directly (or almost) transmitted by an application called API ("Application Program Interface" in English) object oriented. Indeed, the hardware accelerator is associated with a microprocessor which is programmed from to provide a set of predefined functions accessible through this API.

• 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;

To illustrate the role of decoding, for an object composed for example of a bitmap stored somewhere in memory. Its descriptor then contains:

• the address where the image data starts in memory;
• the size of the image;
• the position of the object on the screen;
• the color organization of the bitmap as stored in memory;
• the overall level of transparency of the object;

Imagine that the coordinates of the object are slightly negative compared to the origin of the screen. Only the visible part of the object will have to be processed to be displayed, the rest being clipped. This means that the actual position of the object will have to be determined, that the address of the object in memory will have to be updated to point directly to the first visible pixel. The size of the line segment useful for the volatile construction of a line must also be determined according to the "clipping", but also according to the color organization of the pixels in memory. Thus, for each object, the decoding of the descriptor results in a series of working variables that will be exploited by the hardware accelerator during the volatile construction. If the descriptors can be stored in an external memory, the useful variables will advantageously be stored locally to the hardware accelerator for reasons of accessibility. Some of these variables will undergo changes as the line processes progress. For example, at the end of the descriptor decoding, the address pointer points to the first active line segment of the object stored in memory. But the address pointer will have to point as line processes on the new active line segments.

A second step can be the sorting of objects in descending order of depth. This process allows you to prioritize the order in which the objects will be overlaid on the screen. It takes all its interest when the global transparency of the objects is managed by the hardware accelerator since it then faithfully reproduces the complex transparency between the objects. This means that an object A placed behind an object B will be seen in proportion to the transparency of object B in front of it. The sorting can be done, for example, by first scanning all the objects to determine the most buried object, then starting again the scanning of the objects without taking into account the objects already sorted, until all the objects are sorted. At the end of this scan, each object may for example contain in one of its registers, the index of the next object in a descending order of depth, so that the process line of construction of the image can pass simply d one object to another, and in the order required by complex transparency.

The complex transparency is obtained only by the inventive principle of volatile construction according to the invention and described below.

We will now describe the process performed in the vertical active area VAI. The volatile image construction mechanism is a line process, which means that it executes again for each active line of the screen, that is for each line of the VAI (see figure 3 ).

Line process:

The construction mechanism of a line is synchronized with the display mechanism which simply consists of sending a sequence of pixels at the pixel frequency to the screen. To do this, we can very well use only one line memory for these two mechanisms, knowing that the construction mechanism must then be timed to not update pixels that have not yet been sent to the screen. Two or more line memories can also be used. In this case, some so-called "off screen" used to build the following lines, while a so-called "on screen" is sent to the screen to fill the current line. At the line frequency, for example at the time of the line sync top, the processes are reversed. The memory "off screen" becomes the memory "on screen" and vice versa. The figure 4 illustrates this mechanism on two successive lines Line n and Line n + 1 where we note the role reversal between the two memories 10 and 11.

Construction of the line:

For a line of the given screen, it is a question of recovering all the segments of the objects which must be in this line.

• 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).

To know if an object is in the line, we execute a process allowing successively for each object to identify whether or not the object is present in the screen line considered. The fact that an object is present or not in a line of the screen depends on several parameters that are specific to each object. In the case of a rectangular bitmap object stored as such and displayed as such, there may be mentioned:

• the height of the object (in number of pixels);
• the "y" coordinate of the object (in number of pixels compared to a conventional origin).

If the object is assigned a "clipping" zone, the parameters of this zone will also be taken into account.

If the object has to undergo a vertical "resizing", we will take into account the final size of the object, that is to say on the screen, to determine if a piece of this object is in the line d screen considered.

• 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.

When we know that an object is present in the active line, it is still necessary to determine what is the useful zone of this object in the line considered, to know where and how to recover this zone, and to know where to place it in the line memory. For example, in the case of a rectangular bitmap object stored in memory and displayed anamorphic on the screen, the recovery of the useful segment requires, among other things, to determine:

• the memory address where the first pixel of the object segment is located;
• the number of pixels contained in the segment of the object;
• the law of horizontal and vertical variation between two pixels.

• 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.

The determination of these variables is not enough to recover the useful segment of the object. We must also consider the following object parameters:

• the width of the object stored in memory (in bytes);
• the color organization of the pixels;
• the compression law, if the object is stored in a compressed way.

1. a) de calculer les variables nécessaires à la récupération du segment utile;
2. b) de récupérer les paramètres objet nécessaires;
3. c) de mettre à jour les variables dans les registres en anticipation des prochaines lignes, par exemple le pointeur d'adresse mémoire.

From the point of view of the actions to be carried out: one executes a process allowing successively for each object:

1. a) calculating the variables necessary for the recovery of the useful segment;
2. b) retrieve the necessary object parameters;
3. c) updating the variables in the registers in anticipation of the next lines, for example the memory address pointer.

A process is also performed to access the memory where objects are stored from hardware commands. One can for example speak of "DMA hardware", for "Direct Memory Access" in English, managed by the hardware accelerator, compared to a DMA traditionally managed by a microprocessor.

There is also a process for controlling and monitoring the DMA.

The "hardware" mechanism of volatile construction according to the invention can advantageously be implemented in an FPGA which makes it possible to integrate all the modules and processes necessary for carrying out the method according to the invention. On the figure 5 we see how a hardware accelerator 21 can be architected on such an FPGA.

For the storage of graphic objects, a memory 20 (SDRAM, DDRAM, etc.) is advantageously used whose bandwidth is large enough to allow the volatile construction mechanism to recover enough information (useful data of the active objects) during of the process line. This memory 20 is a random access memory external to the accelerator 21.

1. 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).
2. b) Un registre 15 de stockage des paramètres et variables de travail pour chaque objet.
3. 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.
4. 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.
5. e) Deux mémoires de ligne 19 ou "line buffers" en langue anglaise, (l'une "off screen" et l'autre "on screen" conformément à la figure 4.
6. 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.
7. 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.
8. 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 DMA 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.

On the figure 5 , we distinguish :

1. a) an object manager 14 performing the activation and characterization of the processing specific to the object t (intra-object) as well as management between objects (inter-objects).
2. b) A register 15 for storing the parameters and working variables for each object.
3. c) A "hardware DMA" module 12 controlled by the object manager 14 and capable of searching the data (for example bitmap images) in the external memory 20.
4. d) A buffer 13 for temporarily storing the raw data from the DMA 12, when the DMA processes and a decompression / conversion pipeline 16 are not synchronized.
5. e) Two line memories 19 or "line buffers" in English, (one "off screen" and the other "on screen" in accordance with the figure 4 .
6. f) The decompression / conversion pipeline 16 of the raw data into pixels. More precisely, once the object segment is retrieved by the DMA, it is a question of converting the raw data coming from the DMA into pixels in the output format retained so as to be stored in the line memory. In the case of a bitmap object, this requires knowing:
   • the color organization of the pixels;
   • the law of horizontal variation between two pixels; and
   • the compression law, if the image is stored in a compressed way.
   
   This pipeline also includes ways to transform the pixels. Once the raw data is converted into pixels, it is possible to apply digital processing, such as for example filters or effects on these pixels. We can for example quote:
   • "chroma-keying": the pixel becomes transparent if its value is equal to a reference value called the value of "chroma-key";
   • luminance thresholding: the pixel becomes transparent if the value of its luminance level is lower than a reference value called a threshold value;
   • chrominance thresholding;
   • level of transparency: we modify the level of transparency of the pixel called "alpha" by applying the formula alpha_pixel = alpha_global_objet x alpha_pixel_source;
   • color filters: change the chrominance of the pixel;
   • low-pass, high-pass filters: influence of neighboring pixels to the current pixel by an adapted pipeline;
   • Etc.
7. g) A blender 18 according to the transparency of the pixel in question. Writing the pixels in line memory represents the last step in the line process of the
   volatile construction. Writing a pixel in memory requires knowing:
   • the position of the pixel in the line: coordinate "x" with respect to the origin equal to the first pixel of the screen; and
   • the value of the pixel already present in the line at the same position, especially when the object is semi-transparent.
8. h) A multiplexer 17 selects either the pixel from the main video stream (video_in) or the pixel from the stream from the DMA 12. This mechanism requires that the timing of the accelerator is synchronized and locked on the video source. The operating frequency of the pipeline is several times the pixel frequency of the screen, and the multiplexer selects the video pixel at the rate of once per pixel period (at the pixel frequency). The rest of the time, the multiplexer manages the flow from the DMA 12. When there is no main video stream, it is replaced by a background color ("background"). This architecture example also makes it possible to merge the video with the background color in proportion to a video transparency level (alpha_video_in) without implementing a second merge module.

Thus, the image building method according to the invention makes it possible to manage depth level between graphical objects and video without limit of the maximum number of layers. This number of layers is not sizing at the hardware resources of the accelerator. This method also makes it possible to manage the transparency between the graphic and video objects as a function of the positioning of the objects on the z-axis, irrespective of the number of graphic layers that is not dimensioning to obtain the overall complex transparency.

Claims (12)

1. Method of constructing an image suitable for being displayed on a display system from a plurality of objects and descriptors, each descriptor being associated with each object, a descriptor including graphic parameters defining the nature of the associated object and display parameters for displaying the associated object, for each video frame of the display system, the image is constructed line-by-line by carrying out the following steps:

   - for each line of the display system, on-the-fly construction of this line by retrieving and storing, in real time, in one line buffer, all the pixels relating to the objects intended to be displayed on said line, in order to do this the method further comprising following step:

   - identification indenpendently of each object that must be present on this line according to a set of variables specific to each object;

   - detection in each object thus identified, a useful zone corresponding to the considered line; and

   - conversion of the raw data coming from said useful zone into pixels compatible with the display format,

   - for each pixel of the useful zone and for each identified object, writing a pixel in the line buffer, this pixel is intended to be displayed on a given position on a line of the display system, firstly the position of this pixel in the considered line is determined, and this first pixel is blended with a second pixel currently stored in the line buffer at said same given position, the blender being applied proportionally to the level of transparency of said first pixel;

   - sending these pixels to the display system according to a pixels sequence, such that the complete image is formed only on said display system; the line construction mechanism being line- and frame-synchronized with the display system.
2. Method according to claim 1, characterized in that it comprises the step of using two line buffers, each successively carrying out, in a shifted manner, a construction step then a display step such that, when a first line buffer displays pixels on the current line, pixels intended to be displayed on the following line are constructed and stored in the second line buffer.
3. Method according to claim 1 or 2, characterized in that during the detection step, accessing the memory where the objects are stored from electronic mechanisms and the raw data from the useful intervals is stored temporarily in storage means.
4. Method according to any one of the preceding claims, characterized in that once the raw data is converted into pixels, application of transformations and effects to these pixels.
5. Method according to any one of preceding claims, characterized in that the video frame comprises two separate time intervals, a so-called "vertical blanking interval" (VBI) and a so-called "vertical active interval" (VAI), respectively corresponding to the interval between the two active frames and to the period of display of an active frame, any preparation necessary to the progress of the construction, the construction and display steps are carried out instantly during each vertical active interval.
6. Method according to claim 5, characterized in that said preparation also comprises a sorting of the objects in order of depth so as to hierarchize the order with which the objects will be overlaid on the display system.
7. Method according to claim 6, characterized in that hardware accelerator is suitable for generating the video frame of the display system.
8. Method according to claim 7, characterized in that the hardware accelerator is suitable for synchronizing and locking on the video frame of the display system from synchronization information.
9. Method according to any one of the preceding claims, characterized in that the display system comprises several line- and frame-synchronized screens, and driven by a single controller generating signals that clock from the screens, this controller being located in an accelerator.
10. System for constructing an image suitable to be displayed on a display system from a plurality of objects and descriptors, and in that each descriptor is associated with each object, a descriptor including graphic parameters defining the nature of the associated object and display parameters for displaying the associated object, this system comprising a processing unit combined with a hardware accelerator; the hardware accelerator being used during the construction for constructing the image line by line directly from the objects by means of electronic mechanisms by sate machines, the hardware accelerator being also configured to carry out steps as defined in preceding claims.
11. System according to claim 10, characterized in that the hardware accelerator comprises the following elements:

    - an object manager for activating and characterizing operations linked to the objects,

    - a memory for storing the parameters and variables of each object,

    - a DMA (Direct Memory Access)-type hardware module controlled by the accelerator and suitable for retrieving data about the objects from a memory,

    - a buffer for temporarily storing the data from the DMA hardware module,

    - a module decompressing and converting raw data from the buffer as pixels,

    - a multiplexer for selecting the pixel to be displayed between that from the decompression and conversion module and that from an external source,

    - a blender for blending the pixel from the multiplexer and a currently displayed pixel according to the transparency of the pixel from the multiplexer, and

    - two line buffers successively carrying out in turn the display of previously stored pixels on the current line of the display system, and the storage of pixels from the blender which will be displayed on the following line.
12. System according to claim 10 or 11, characterized in that it comprises means for synchronizing on a video source and inserting graphic information into a video flow of said video source, not stored in the memory.

Images