Brevet FR3038995A1 — publié le 20170120

F4GROUP5 FRD Dispositif interactif L'invention concerne le domaine des dispositifs web, et en particulier les dispositifs permettant une interaction. Plus particulièrement, l'invention concerne le domaine de la cartographie sur Internet. La cartographie sur Internet a longtemps été limitée à la reproduction de cartes papiers sous forme d'images. Cela était imprécis et fortement consommateur en bande passante, et posait des problèmes de pertinence, puisque les images n'offraient pas de moyen simple de mise à l'échelle ni de personnalisation. Des acteurs importants des nouvelles technologies ont modifié cette situation en proposant des cartes sur Internet qui étaient plus légères, dont la mise à l'échelle est adaptative, et qui permettent à l'utilisateur de parcourir rapidement une carte donnée. Pour note, comme l'invention, ces solutions sont toutes de type « pur Web », c'est-à- dire qu'un client Web (un navigateur ou une application de smartphone) interagit avec un serveur pour obtenir les données, mais ne stocke rien en local, hormis du cache. Toutes les données proviennent du serveur, en temps réel sauf pour les données du cache. Cela est crucial car, compte tenu des bandes passantes actuellement disponibles, les contraintes sur ce qu'il est possible d'obtenir en termes d'effets visuels sont très fortes si l'on souhaite maintenir un affichage fluide. Ces mêmes acteurs ont rajouté sur ces cartes des couches (« layer » en anglais) d'information afin d'ajouter un peu d'information, comme l'emplacement de certains commerces ou monuments, etc. Cependant, il s'agit littéralement de couches au sens graphique du terme : la nature de l'interaction est limitée à l'affichage d'un texte, la zone cliquable permettant cette interaction est limitée à une zone de taille réduite choisie de manière arbitraire, et ne peut pas par exemple concerner un immeuble entier, ou un parc dans une ville. Des efforts ont également été faits pour apporter un peu de réalisme par l'ajout de vue en trois dimensions pour certains bâtiments. Mais là encore, il s'agit d'éléments purement graphiques, dépourvus d'interaction. 3038995 2 En réponse à ces problèmes, la Demanderesse a développé un dispositif et un procédé ayant fait l'objet de la demande FR 1555807. Ce type de dispositif, comme d'autres dès qu'il est fait intensément appel aux ressources Web (ce qui est souvent le cas dès que de la 3D est prévue), est très exigeant en termes de ressources, et l'optimisation de 5 l'expérience utilisateur est complexe si l'on veut l'exploiter au maximum. L'invention vient améliorer la situation. À cet effet, l'invention propose un dispositif interactif comprenant une interface utilisateur agencée pour définir au moins une requête d'affichage comprenant au moins des données de localisation et des données 10 d'affichage, une interface réseau agencée pour émettre une requête de données de page Web en correspondance d'une requête d'affichage, une mémoire pour recevoir des données de page Web correspondantes, les données de pages Web comprenant des données de cartographie et/ou des données d'objet. 15 Le dispositif comprend en outre un interpréteur Web agencé pour permettre l'affichage une page Web et comprenant un moteur 3D agencé pour calculer des données d'affichage en trois dimensions à partir de données d'objet et un moteur d'affichage agencé pour permettre d'afficher des données de page Web à partir de données de cartographie et/ou de données d'affichage en trois dimensions. L'interpréteur Web 20 comprend en outre un gestionnaire fonctionnant par cycle d'exécution et agencé pour déterminer une liste comprenant au moins une opération pouvant être une requête de données d'objet et/ou de données de cartographie ou un traitement par le moteur 3D ou le moteur d'affichage de données reçues, le gestionnaire exécutant la ou les opérations de la liste d'un cycle d'exécution donné en fonction de l'ordre des opérations dans la 25 liste, du nombre de requêtes en cours, et de la durée de cycle d'exécution donné. Ce dispositif est particulièrement avantageux car il permet d'exécuter en mode Web un programme appelant de très nombreux objets tout en préservant l'expérience utilisateur. 30 Selon diverses variantes, le dispositif peut présenter une ou plusieurs des caractéristiques suivantes : - le gestionnaire exécute les opérations selon leur ordre dans la liste, 3038995 3 - le gestionnaire exécute une requête de données lorsque le nombre de requêtes de données en cours d'exécution est inférieur à un nombre de requêtes seuil, - le gestionnaire cherche à exécuter les opérations de requêtes de données avant les opérations de traitement, 5 - le gestionnaire détermine entre l'exécution de deux opérations si une durée entre le temps courant et le temps du prochain cycle d'exécution est supérieur à une valeur temporelle seuil, et cesse de parcourir la liste d'opérations le cas échéant, - le gestionnaire détermine plusieurs listes présentant un rang de priorité, et exécute les opérations des listes par rang de priorité décroissante, 10 - le gestionnaire exécute les opérations d'une liste de rang de priorité inférieure lorsque toutes les opérations de traitement de la liste de rang de priorité immédiatement supérieur ont été exécutées. L'invention concerne également un produit de programme d'ordinateur comprenant des 15 portions de code de programme pour mettre en oeuvre le dispositif interactif lorsque ledit programme est exécuté sur un ordinateur D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de la description qui suit, tirée d'exemples donnés à titre illustratif et non limitatif, tirés des 20 dessins sur lesquels : - la figure 1 représente un diagramme schématique d'un dispositif selon l'invention, dans son environnement de fonctionnement, - la figure 2 représente un diagramme schématique d'une boucle de fonctionnement du dispositif de la figure 1, et 25 - la figure 3 représente un diagramme schématique d'une opération de mise à jour de la figure 2. Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la 30 présente invention, mais aussi contribuer à sa définition, le cas échéant. 3038995 4 La présente description est de nature à faire intervenir des éléments susceptibles de protection par le droit d'auteur et/ou le copyright. Le titulaire des droits n'a pas d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa description, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il 5 réserve intégralement ses droits. La figure 1 représente un schéma générique d'un dispositif interactif 2 selon l'invention dans son environnement. 10 L'exemple décrit ici trouve une application particulièrement intéressante dans le domaine de la cartographie en ligne. Cependant, l'invention trouve son application dans toute situation impliquant un affichage en trois dimensions impliquant une interactivité avec l'utilisateur dans un contexte « tout serveur », ou « tout flux (streaming en anglais) », c'est-à-dire que toutes les données sont issues d'un serveur, le dispositif ne 15 stockant rien localement (y compris le code JavaScript du moteur 3D dans l'exemple décrit ici) à part du cache. Cette application est particulièrement adaptée à un usage Web, mais pourra être utilisée sous forme d'application pour smartphones par exemple, dans un format autre qu'une page Web. Dans ce cas, l'application pourra stocker les données de code du moteur 3D par exemple, mais ne visera toujours pas à stocker 20 d'autres données que du cache, c'est-à-dire que les données stockées ne sont pas persistantes. Le dispositif 2 comprend une mémoire 4, un affichage 6, une interface utilisateur 8, une interface réseau (non représentée) et un interpréteur Web 10. 25 La mémoire 4 peut être tout moyen de stocker des informations : de la mémoire Flash, de la mémoire RAM, un disque dur, une connexion à un stockage déporté ou dans le cloud, etc. Dans le cadre de l'invention, la mémoire 4 sert à stocker les données en vue du traitement. Comme mentionné plus haut, les données de la mémoire 4 n'ont pas 30 vocation à être persistantes, sauf à servir de cache dont la durée de validité est programmée et limitée. En effet, l'invention vise une application temps réel où toutes les données sont obtenues du serveur, sans stockage local préalable. 3038995 5 L'affichage 6 peut être tout affichage classique du type écran, projecteur vidéo, lunettes à projection, etc. L'interface utilisateur 8 permet à l'utilisateur du dispositif 2 de choisir les paramètres d'affichage de la carte ainsi que l'emplacement qu'il souhaite visualiser. 5 Les paramètres d'affichage peuvent porter de manière non restrictive sur la latitude et la longitude, le niveau de zoom, l'angle du vue, l'orientation. Ces paramètres sont classiques dans ce type d'application. L'invention propose également d'autres paramètres d'affichage, dits de « personnalisation ». 10 En effet, dans les applications connues, il est possible d'activer ou de désactiver l'affichage de certains éléments. Cependant, il s'agit uniquement d'afficher ou de ne pas afficher les couches d'informations correspondantes. Il ne s'agit pas de permettre de personnaliser l'affichage d'un jeu restreint d'objets, par exemple. D'ailleurs, il n'est pas possible de parler « d'objets » dans les applications de l'art antérieur. Il s'agit de 15 cartographies simples, éventuellement munies d'affichages en trois dimensions, mais non individualisables. À l'inverse, l'invention permet de rendre chaque élément de la cartographie indépendant, comme objet informatique. L'interpréteur Web 10 peut être réalisé par tout navigateur mettant en oeuvre 1'HTML, 20 le JavaScript et le WebGL. Comme on le verra dans ce qui suit, l'interpréteur Web 10 comprend un moteur 3D, un moteur d'affichage, un interpréteur WebGL et un gestionnaire (non représentés). Dans l'exemple décrit ici, l'utilisateur accède à la cartographie par le biais d'une page Web. Cette page Web contient à la fois du code HTML, du code JavaScript et du code WebGL. Le code JavaScript définit le 25 moteur 3D, qui reçoit des données d'objet à représenter sur la portion de carte requise par l'utilisateur, et transforme ces données d'objet en données de faces. Les données de face sont transmises à l'interpréteur WebGL qui interagit avec les ressources matérielles du dispositif 2 pour calculer les données à afficher à proprement parler. L'affichage à proprement parler est géré par le moteur d'affichage de l'interpréteur Web, sur la base 30 des données de cartographies reçues et des données d'affichage en trois dimensions calculées, comme on le verra plus bas. Le gestionnaire vient ordonnancer l'ensemble des opérations, comme cela sera décrit en référence à la figure 3. 3038995 6 Bien que dans l'exemple décrit ici l'interpréteur Web 10 utilise WebGL pour le rendu des objets en trois dimensions, l'interpréteur WebGL est optionnel et peut être remplacé par toute autre technologie appropriée. D'une manière générale, il doit être compris que le moteur 3D commande les actions nécessaires en coordination avec le gestionnaire 5 afin de calculer les données d'affichage en trois dimensions, le moteur d'affichage se chargeant uniquement de l'affichage. Comme mentionné précédemment, toutes les données sont obtenues d'un serveur 12 qui comprend une mémoire 14 et un moteur 16. La mémoire 14 est similaire à la 10 mémoire 4, sauf en ce qu'elle stocke toutes les informations utiles au fonctionnement du dispositif 2 (contrairement à la mémoire 4 qui stocke quasi-exclusivement du cache). Le moteur 16 est un élément qui reçoit les requêtes de données de pages Web du dispositif 2. Comme on l'a vu plus haut, à partir des données reçues par l'interface 15 utilisateur 8, le dispositif 2 définit une requête d'affichage de cartographie à partir des données de localisation et des données d'affichage. Ces données définissent ensemble une zone géographique. Sur la base de cette zone géographique, le dispositif 2 émet une requête de données de page Web vers le serveur 12, et le moteur 16 sélectionne dans la mémoire 14 les données de cartographie ainsi que les données des objets qui 20 correspondent à cette requête. Dans l'exemple décrit ici, les données de cartographie de la mémoire 14 sont stockées sous la forme de tuiles (« tiles » en anglais) en plusieurs niveaux de détails. Ainsi, chaque tuile se décompose en quatre sous-tuiles quand le niveau de zoom augmente, et 25 inversement, etc. Dans l'exemple décrit ici, les données de cartographie contiennent pour chaque tuile la liste des objets qui lui sont associés. En variante, les données d'objets pourraient contenir des données indiquant les tuiles auxquelles ils sont rattachés. 30 Dans l'exemple décrit ici, l'identification des tuiles est implicite, c'est-à-dire que le dispositif 2 peut déterminer quelles sont les données de tuile à demander au serveur 12 via la requête de données de page Web. Ainsi, cette dernière est une pure requête de 3038995 7 ressources, et le serveur 12 ne développe aucune « intelligence ». En variante, la requête de données de page Web pourrait être plus abstraite et contenir les données de localisation et les données d'affichage, et le serveur 12 se chargerait via le moteur 16 de déterminer les données de tuile pertinentes. 5 Les données des objets comprennent, dans l'exemple décrit ici, des données permettant de définir de manière abstraite l'affichage tridimensionnel de ces objets. Ainsi, pour un bâtiment, les données d'objet comprennent des données définissant l'empreinte au sol, la forme de son toit, et des données de hauteur de bâtiment. Un bâtiment peut présenter 10 plusieurs hauteurs. Ainsi, lorsque le moteur 3D calcule les données de face d'un bâtiment, il procède en « élevant » un contour correspondant à l'empreinte du bâtiment au sol à la hauteur des données d'objet correspondantes, et en calculant les triangles définissant chacune des faces de l'objet ainsi défini. Une autre manière de voir cela est de considérer qu'un bâtiment est « extrudé » à travers son empreinte au sol sur sa 15 hauteur. Pour un sol ou un relief, il est procédé de manière similaire : à partir des tuiles des données de cartographie, un maillage du sol par triangulation est réalisé. Ce maillage peut être utilisé pour représenter des reliefs grâce à des données d'objet de type données de relief, qui comprennent des données de localisation permettant d'indiquer la tuile auxquelles elles correspondent, et des données d'altitude pour 20 indiquer la hauteur du relief. Lorsque des données de relief sont reçues, les sommets des triangles des tuiles correspondants aux données de localisation correspondantes sont élevés à la hauteur désignée par les données d'altitude correspondantes. Les objets peuvent également être immatériels, et désigner par exemple une ligne de bus ou de métro, ou un réseau de distribution d'eau ou d'électricité etc. 25 De manière avantageuse, mais optionnelle, en fonction de la requête de données de page Web, le moteur 16 peut sélectionner les données d'objets en fonction d'une valeur indiquant leur taille. Ainsi, si le zoom est très lointain, le moteur 16 ne retourne que les détails dont la taille est pertinente compte tenu de la résolution de la carte reproduite. Et 30 dès qu'un utilisateur zoome, le moteur 16 enverra les données d'objet dont la taille les a rendus pertinents compte tenu de la résolution recherchée. Cela présente l'avantage de permettre de contrôler la charge de téléchargement et de traitement côté dispositif, mais 3038995 8 également d'améliorer l'expérience visuelle : au fur et à mesure qu'un utilisateur zoome, le monde se précise sous ses yeux. La figure 2 représente un diagramme schématique d'une boucle de fonctionnement du 5 dispositif de la figure 1. Dans une opération 200, le dispositif 2 réalise l'initialisation de l'affichage de la cartographie. Pour cela, les données de localisation et les paramètres d'affichage sont obtenus à partir de l'interface utilisateur 8, et le dispositif 2 met en oeuvre l'interface 10 réseau pour émettre une requête d'affichage vers le serveur 12 avec ces données. En réponse, le serveur 12 émet des données comprenant le code du moteur 3D, ainsi que les données de cartographie et les données d'objet correspondantes. Dans les échanges suivants, le code du moteur 3D n'est plus transmis, sauf pour d'éventuelles mises à jour. 15 Dans une opération 220, le dispositif 2 reçoit les données de cartographie et les données d'objet, ainsi que le code du moteur 3D. Sur la base de ces données, l'interpréteur Web 10 affiche par exemple en priorité les données de cartographies, qui donnent à l'utilisateur une vue rapide du « fond de carte ». Dans le même temps, le moteur 3D traite les données d'objet pour calculer les données de face correspondantes. Les 20 données de faces de chaque objet sont regroupées, et entrées dans un bloc de données de face, au moyen d'un bloc mémoire de type tableau à valeurs sur 32-bits (en anglais « Float32Array ») utilisé par l'interface WebGL, ci-après Buffer32. Le Buffer32 est un outil classique en WebGL qui sert à transmettre une requête de calcul de données d'affichage 3D à une ressource matérielle à partir de données de faces définies dans le 25 Buffer32. L'interpréteur WebGL transmet le Buffer32 contenant toutes les données de face à la ressource matérielle du dispositif 2 pour calcul des données pour l'affichage en trois dimensions des données d'objet. Chaque Buffer32 peut contenir des données relatives à 65536 sommets de triangles. Lorsqu'un Buffer32 est « rempli », le moteur 3D en instancie un autre, tout en préservant les correspondances entre les données de 30 chaque Buffer32 et les objets auxquels elles correspondent. En variante, le Buffer32 pourrait être réalisé avec un autre type de tableau de valeurs. Les données de face 3038995 9 peuvent comprendre des données définissant des sommets, des faces, ou encore des informations de mapping de texture sur les triangles. Simultanément, l'interpréteur Web 10 conserve une correspondance entre les données 5 de face regroupées pour chaque objet du Buffer32 et les identifiants des objets correspondants. Ainsi, si un utilisateur veut sélectionner un objet, il clique avec la souris sur un emplacement de ce dernier à l'écran (ou un autre moyen de désignation d'un emplacement à l'écran comme l' évènement « onMouseOver » JavaScript). En réponse, l'interpréteur WebGL émet une requête de type rayon (« ray picking » en anglais), qui 10 retourne la face dans le Buffer32 qui a été désignée par le clic, et, sur la base de cette correspondance, l'interpréteur Web 10 est capable de savoir quel objet a été cliqué ou désigné, et d'offrir à l'utilisateur un menu d'options pour réaliser des requêtes spécifiques à cet objet ou à une classe d'objets lui correspondant auprès du serveur 12, ou encore afficher cet objet de manière particulière. En variante, d'autres méthodes que 15 le ray picking pourraient être utilisées pour déterminer la face qui se trouve sous la souris (par exemple le rendu en un seul point de la scène avec colorisation des faces sur la base de leur identifiant et identification de la face à partir de la couleur de ce point). Cette caractéristique est fondamentale pour deux raisons : 20 - la concaténation d'un ensemble considérable de données de face dans quelques Buffer32 permet de réaliser un affichage d'une grande quantité d'objets sans perdre en fluidité.; et - le maintien de la correspondance entre les objets et les données de face qui leur correspondent dans le bloc de données de face permet de rendre les objets réellement 25 interactifs. Avant, les prétendus « objets » étaient des points ponctuels, ou des images en trois dimensions non cliquables. Dans le cas des points, il était difficile de cliquer, et la zone cliquable était sans rapport avec l'objet concerné. De plus, du fait de l'approche 30 « couche de données superposée » associée, l'idée n'était pas de rendre les objets interactifs, mais de rajouter une couche d'information simpliste. 3038995 10 L'invention permet au contraire de produire un nouveau type de carte dans laquelle l'interaction est possible et intuitive : si l'on veut avoir un renseignement sur une ligne de métro ou sur un bâtiment, ou sur la végétation d'une rue, il suffit de cliquer n'importe où sur l'objet correspondant. 5 Dans les cartes existantes, la plupart des détails étaient omis pour la seule raison qu'ils représentaient une masse d'information impossible à traiter d'un bloc sans ralentir de manière excessive le téléchargement et/ou l'affichage. Grâce au passage au contexte « objet », les détails sont eux-mêmes des objets. Il est donc possible de choisir la 10 priorité d'affichage des objets, les détails les plus précis, ou « moins utiles » pouvant être affichés en dernier, ou ne pas être affichés du tout. De plus, le fait de transformer la carte, d'une collection de tuiles de fonds de carte juxtaposées, en un monde composé d'objets individuels génère une quantité 15 conséquente de nouvelles applications inenvisageables précédemment. Par exemple, il devient possible de réaliser des applications immobilières ou de géolocalisation qui fournissent une information rapide et pertinente. Dans ce dernier cas, on peut imaginer qu'un clic sur un hôpital permettra de connaître les spécialités qui y sont pratiquées, ou encore qu'un clic sur un bâtiment particulier indiquera quels soins particuliers sont 20 dispensés et/ou les chambres du ou des services concernés, de cliquer sur un banc particulier pour indiquer qu'il a été vandalisé etc. Et les autres détails environnants peuvent être priorisés de manière inférieure pour préserver l'expérience utilisateur en lui fournissant l'information qui l'intéresse en priorité. Il devient donc possible d'introduire une quantité énorme de « couches d'informations » de manière simple dans des cartes, 25 là où cela était précédemment impossible ou incommode du fait de l'utilisation de « layers » superposées et non directement liées à des objets individualisés. Enfin, dans une opération 240, le dispositif 2 met à jour l'affichage 6 en fonction des entrées utilisateur via l'interface utilisateur 8. Ainsi, si l'utilisateur change de niveau de 30 zoom, déplace la carte ou interagit avec l'un des objets, l'interpréteur Web 10 appelle le serveur 12 pour obtenir de nouvelles données et calcule les données modifiées en conséquence. 3038995 11 La figure 3 représente un exemple de mise en oeuvre des opérations 220 et 240. En effet, le dispositif de l'invention permet d'afficher un monde présentant une richesse inégalée. Comme on vient de le voir, cette richesse est rendue en partie possible grâce à la réalisation de calculs sur le dispositif, par exemple pour calculer les données de face des 5 objets. Malgré toutes les optimisations offertes par l'invention, il va de soi que, si le dispositif attend de disposer de toutes les données pour afficher la carte, tant à l'initialisation que lors d'un changement important de position, le délai d'affichage risque d'être très 10 important, et l'expérience utilisateur en souffrira. Cela est d'autant plus important que les navigateurs Web et autres dispositifs embarquant un interpréteur Web sont limités dans le nombre de requêtes simultanées qu'ils sont capables d'émettre. En effet, ils peuvent émettre en général entre 25 et 50 15 requêtes d'obtention de données de pages Web en simultané, sans que ce nombre soit par ailleurs connu ou standardisé. Lorsque l'on considère cette limitation au vu du dispositif décrit ci-dessus, il apparaît assez rapidement que, au moins dans la phase d'initialisation de la carte, le dispositif va 20 rapidement saturer le nombre de requêtes de données de pages Web, et que cette saturation dépendra d'un facteur qui ne peut pas être maîtrisé. Une solution doit donc être trouvée pour permettre de conserver une bonne expérience utilisateur dans un environnement complexe comme celui du dispositif décrit ci-dessus, qui fait appel à de très nombreuses ressources Web. 25 Pour cela, la Demanderesse a développé le gestionnaire de l'interpréteur Web. Ce gestionnaire a pour rôle l'ordonnancement des opérations afin d'optimiser l'expérience utilisateur. Dans l'exemple qui est décrit ici, il est considéré qu'un affichage à 60 images par seconde est optimal, et le gestionnaire est optimisé en ce sens. Dans d'autres 30 variantes, selon d'autres critères, le gestionnaire pourra être agencé différemment. 3038995 12 Le gestionnaire organise donc les opérations au sein de l'interpréteur Web. Pour cela, il gère deux types d'opérations : les requêtes de données, et les traitements de données. Les requêtes de données sont toute requête de données de pages Web, qu'elle concerne 5 des données de cartographie ou des données d'objet ou des données de mise à jour du code du moteur 3D. D'une manière générale, ces requêtes peuvent donc être vues comme tout échange entre le dispositif et l'extérieur, et qui peuvent donc saturer comme expliqué plus haut. 10 À l'inverse, les traitements de données concernent toutes les opérations qui sont internes au dispositif, comme par exemple, la triangulation de données d'objets pour obtenir des données de face, leur rangement dans des données de bloc de face, la transmission de données de bloc de faces à l'interpréteur WebGL pour le calcul des données d'affichage en trois dimensions, etc. 15 Il faut aussi comprendre que les requêtes de données et les traitements de données ne sont pas indépendants : un traitement de données est directement ou indirectement lié à une requête de données qui s'est achevée. 20 Le dispositif fonctionne donc par cycles d'exécution. Au sein d'un cycle d'exécution donné, le gestionnaire détermine la liste des opérations « en cours », c'est-à-dire à réaliser, et choisit celles de ces opérations qui vont être exécutées pour ce cycle. Le téléchargement de nouvelles données est réalisé en priorité, puisque ce sont ces données qui une fois téléchargées sont traitées pour être affichées. Cela est d'autant plus 25 important que, si le temps de traitement des données est relativement prévisible (car dépendant de ressources locales), les temps de téléchargement le sont moins (les réseaux pouvant présenter une latence incontrôlable). Sur le principe, pour un cycle d'exécution donné, le gestionnaire va lancer en priorité 30 les requêtes de données nouvellement générées et les requêtes de données non lancées dans le ou les cycles précédents. Ensuite, une fois que tous les téléchargements possibles ont été lancés, le gestionnaire alloue du temps aux opérations de traitement. 3038995 13 Dans l'exemple décrit ici, la situation est encore un peu plus complexe, car le gestionnaire va gérer plusieurs listes d'opérations en fonction de leur priorité. Par exemple, une opération portant sur une tuile de fond de carte aura priorité sur une opération de détail. Pour cela, le gestionnaire gère plusieurs listes, qu'il cherche à vider 5 les unes après les autres. Ainsi, le gestionnaire va d'abord lancer toutes les requêtes de données de la première liste (dans la limite de la quantité possible simultanément), puis tous les traitements de données de la première liste, puis une fois qu'il aura épuisé cette première liste, il passera à la deuxième liste etc. 10 Le gestionnaire part donc, pour un cycle donné d'une opération 300 à partir d'un tableau d'opérations (requête ou traitement) à exécuter OP[], d'un indice i de priorité de liste initialisé à 0, et un tableau de traitements à exécuter PR[], lui aussi initialisé à 0. Dans une opération 305, une fonction Tick() vérifie si un nouveau cycle d'exécution est 15 si proche qu'aucune nouvelle opération ne peut être lancée. Si c'est le cas, alors l'opération 305 se répète jusqu'à ce que nouveau cycle commence. Si ce n'est pas le cas, alors dans une opération optionnelle 310, le gestionnaire peut tenir compte d' évènements externes pour modifier son fonctionnement avec une fonction 20 Chng(). Par exemple, si l'utilisateur se met à se déplacer avec vitesse dans la carte, le gestionnaire pourra changer les listes de priorité (par exemple, ne plus charger les détails, rendre plus prioritaires des données de tuile qui étaient auparavant en bord 25 d'image et qui deviennent centrales compte tenu du déplacement), abandonner certaines opérations qui ne sont plus pertinentes (par exemple, une requête pour une tuile qui ne sera plus affichée compte tenu de la direction de déplacement, modifier la durée de cycle pour tenir compte d'informations entrées par l'utilisateur (qui peut privilégier plus de détails ou au contraire privilégier une parfaire fluidité, etc.), etc. 30 Ensuite, deux boucles commencent dans lesquelles le tableau d'opérations OP[] d'indice i va être progressivement dépilé pour lancer l'exécution des requêtes de 3038995 14 données (première boucle), avant de lancer l'exécution des traitements de données (deuxième boucle). Dans ce qui suit, on parlera indifféremment de tableau OP[] d'indice i ou de liste OP[i], le tableau étant uniquement une manière de mettre en oeuvre les listes de priorités différentes. Lorsque ces deux boucles sont terminées sans que le 5 cycle d'exécution se termine, l'opération 305 reprend avec la liste de priorité suivante. La première boucle commence avec une opération 315 par le dépilage d'une opération x courante de la liste OP[i]. Dans une opération 320, une fonction Req() détermine si l'opération x est une requête, et si le nombre maximal de requêtes simultanées est atteint 10 ou non. S'il s'agit d'une requête et que le nombre de requêtes simultanées n'est pas atteint, alors dans une opération 325, une fonction Proc() lance l'exécution de la requête de données. Dès que le téléchargement des données correspondantes est réalisé, l'interpréteur Web 15 modifie la liste d'opérations en conséquence pour introduire une opération de traitement de données relatives aux données téléchargées. S'il ne s'agit pas d'une requête, ou si le nombre de requêtes simultanées est atteint, alors dans une opération 330, le gestionnaire exécute une fonction Push() qui analyse 20 l'opération x et, s'il s'agit d'un traitement de données, l'introduit dans la liste PR[i] des traitements à effectuer. S'il s'agit d'une requête et que le nombre de requêtes simultanées est pas atteint, alors la fonction Push() déplace l'opération x dans la liste des opérations à traiter dans le cycle d'exécution suivant. 25 Enfin, après l'opération 325 ou l'opération 330, une fonction Stop() 335 détermine si le gestionnaire peut encore initialiser de nouvelles tâches ou non. Si ce n'est pas le cas, alors l'indice i est réinitialisé à 0 dans une opération 340, et le prochain cycle d'exécution est attendu avec l'opération 305. Si c'est le cas, alors la première boucle reprend avec l'opération 320 pour dépiler l'opération suivante de la liste de priorité 30 d'indice i. 3038995 15 Lorsque la liste d'opérations d'indice i (OP[i]) est vide, la deuxième boucle commence. Dans cette deuxième boucle, la liste PR[i] va être dépilée pour exécuter les opérations de traitement, d'une manière similaire à la première boucle, mais elle est plus simple car par construction, la liste PR[i] ne contient que des opérations de traitement. 5 Ainsi, dans une opération 345, la liste PR[i] est dépilée, et dans une opération 350, la fonction Proc() est à nouveau appelée pour exécuter le traitement x courant. Pour cela, l'interpréteur Web instancie un Web Worker, qui est un composant Javascript qui permet de tirer parti de l'architecture multi-coeurs des processeurs modernes. En 10 variante, l'interpréteur Web peut fonctionner sans Web Worker. Ensuite, dans une opération 355, la fonction Stop() est relancée de la même manière que l'opération 335. Lorsque l'opération 335 indique une fin de cycle d'exécution la deuxième boucle se termine avec l'opération 340 puis l'attente du cycle d'exécution 15 suivant avec l'opération 305. Sinon, la deuxième boucle se poursuit avec l'opération 345 jusqu'à ce que la liste PR[i] soit vide ou que la fonction Stop() indique une fin de cycle d'exécution. Lorsque la liste PR[i] est vide, alors le gestionnaire peut passer à la liste de priorité 20 suivante, en incrémentant l'indice i dans une opération 360, et en vérifiant sur la liste d'indice i existe dans une opération 365. Si c'est le cas, alors le cycle d'exécution se poursuit avec la première opération 320 de la première boucle de la nouvelle liste de priorité. Sinon, alors l'indice i est réinitialisé à 0 dans une opération 370, et le prochain cycle d'exécution est attendu avec l'opération 305. 25 Le mode de fonctionnement décrit avec la figure 3 est particulièrement intéressant car il permet de tenir à jour en permanence les listes d'opérations d'un cycle d'exécution à l'autre. Lorsqu'une nouvelle opération est introduite, l'interpréteur Web la transmet au gestionnaire qui la reçoit dans une des listes de priorisation et l'exécute aussi vite que 30 possible. 3038995 16 De plus, ce fonctionnement assure un affichage aussi rapide que possible : le moteur d'affichage n'attend pas que toutes les données soient arrivées pour commencer à afficher la carte. Par la nature même de la priorisation, les données les plus importantes seront reçues en premier et affichées dès que possible. Ainsi, le monde se construit sous 5 les yeux de l'utilisateur. Par exemple, pour une utilisation dans le domaine de l'immobilier : - Liste 0 (priorité maximale) : les localisations des biens immobiliers, car il est plus important pour l'utilisateur de voir qu'il y a biens qui correspondent à ses critères de 10 recherche quelque part sur la carte que de pouvoir se repérer, - Liste 1 : le fond de carte, car il permet à l'utilisateur de se repérer, - Liste 2 : l'information définissant le relief du terrain et les bâtiments, - Liste 3 : les arbres, fontaines, vignes, cimetières... 15 En variante, il peut n'y avoir qu'une seul liste de priorisation. Comme mentionné précédemment, certains éléments peuvent voir leur priorité et/ou leur inclusion dans les listes de priorisation dépendre de leur nature. Par exemple, les objets de type « détails » peuvent ne pas être affichés lorsque le zoom indique une distance trop importante. Ainsi, dans l'exemple décrit ici, Les détails loin à l'horizon donc très petits ne sont pas 20 demandés par le client. À chaque type de détail est associée une distance max, qui ne dépend pas de sa taille uniquement. Par exemple, les pylônes à l'horizon ne sont jamais demandés, mais les forêts le sont toujours. De la même manière, la fonction Chng() peut tenir compte du fait que l'utilisateur est en 25 train de bouger la caméra pour adapter les priorités. Ci-après, quelques exemples de traitements qui peuvent être gérés par la fonction Chng(). Après chaque déplacement ou zoom demandé par l'utilisateur, l'interpréteur Web trie les demandes pour traiter en priorité les opérations en rapport avec ce qui est le plus 30 proche du centre de l'écran car c'est l'endroit que regarde l'utilisateur. 3038995 17 Quand l'utilisateur bouge la carte, les opérations de requêtes peuvent voir leur priorité changer : - certaines opérations peuvent être désactivées, par exemple en ne traitant pas les listes les moins prioritaires par le gestionnaire (dans l'exemple immobilier décrit plus haut, 5 seules, par exemple on ne demande plus que les localisations des biens immobiliers (Liste 0) et éventuellement le fond de carte (Liste 1) - le gestionnaire demande au serveur des tuiles de niveau de détail inférieur (donc présentant un contenu plus synthétique) à celle qu'il demanderait quand la carte est immobile, mais pour une utilisation à la taille supérieure : cela permet de charger de 10 plus vite donc augmente la fluidité, et même si la carte affichée est moins précise donc moins nette, le mouvement fera que l'utilisateur ne s'en rendra pas compte, - les demandes de tuiles pour lesquelles aucunes données n'ont encore été reçues voient leur priorité être augmentée par rapport aux tuiles pour lesquelles des données sont déjà disponibles mais dans un niveau de détail inférieur au niveau demandé. 15 - toute opération qui concerne quelque chose qui n'est plus visible par l'utilisateur est annulée, donc supprimée de la liste de priorisation. Par ailleurs, une tuile affichée sera gardée en cache, jusqu'à ce que le centre de la carte soit à une distance choisie de cette tuile (par exemple 10 km). 20 Les opérations de traitement peuvent également voir leur priorité changer : - quand la carte bouge, le gestionnaire diminue le temps accordé à la génération des détails et des bâtiments, qui vont ainsi apparaître plus tard sans provoquer de saccades dans le mouvement, 25 - si le gestionnaire détermine que le dispositif n'est pas assez puissant pour réaliser tous les traitements, certains objets peuvent être sélectivement désactivés, comme des objets de décoration (la texture et l'animation de l'eau des cours d'eau, etc.), - les traitements des données de bloc de données de faces peuvent être rendus prioritaires par rapport aux traitements des données de textures pour leur envoi aux 30 ressources matérielles de calcul. D'autres variantes pourront apparaître à la lecture des revendications qui suivent. REVENDICATIONS1. Dispositif interactif, comprenant une interface utilisateur (8) agencée pour définir au moins une requête d'affichage comprenant au moins des données de localisation et des données d'affichage, une interface réseau agencée pour émettre une requête de données de page Web en correspondance d'une requête d'affichage, une mémoire (4) pour recevoir des données de page Web correspondantes, les données de pages Web comprenant des données de cartographie et/ou des données d'objet, le dispositif (2) comprenant en outre un interpréteur Web (10) agencé pour permettre l'affichage une page Web et comprenant un moteur 3D agencé pour calculer des données d'affichage en trois dimensions à partir de données d'objet et un moteur d'affichage agencé pour permettre d'afficher des données de page Web à partir de données de cartographie et/ou de données d'affichage en trois dimensions, l'interpréteur Web (10) comprenant en outre un gestionnaire fonctionnant par cycle d'exécution et agencé pour déterminer une liste comprenant au moins une opération pouvant être une requête de données d'objet et/ou de données de cartographie ou un traitement par le moteur 3D ou le moteur d'affichage de données reçues, le gestionnaire exécutant la ou les opérations de la liste d'un cycle d'exécution donné en fonction de l'ordre des opérations dans la liste, du nombre de requêtes en cours, et de la durée de cycle d'exécution donné. Dispositif selon la revendication 1, dans lequel le gestionnaire est agencé pour exécuter les opérations selon leur ordre dans la liste. Dispositif selon la revendication 1 ou 2, dans lequel le gestionnaire exécute une requête de données lorsque le nombre de requêtes de données en cours d'exécution est inférieur à un nombre de requêtes seuil. Dispositif selon l'une des revendications précédentes, dans lequel le gestionnaire cherche à exécuter les opérations de requêtes de données avant les opérations de traitement. 20 2. 25 3. 30 4. 3038995 19 5. Dispositif selon l'une des revendications précédentes, dans lequel le gestionnaire détermine entre l'exécution de deux opérations si une durée entre le temps courant et le temps du prochain cycle d'exécution est supérieur à une valeur temporelle seuil, et cesse de parcourir la liste d'opérations le cas échéant. 5 6. Dispositif selon l'une des revendications précédentes, dans lequel le gestionnaire détermine plusieurs listes présentant un rang de priorité, et exécute les opérations des listes par rang de priorité décroissante. 10 7. Dispositif selon les revendications 3, 4 et 6, dans lequel le gestionnaire exécute les opérations d'une liste de rang de priorité inférieure lorsque toutes les opérations de traitement de la liste de rang de priorité immédiatement supérieur ont été exécutées. 15 8. Produit de programme d'ordinateur comprenant des portions de code de programme pour mettre en oeuvre le dispositif selon l'une des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur.