Soutenance mémoire
Étude de librairies WebGL pour la plateforme et d’autres projets
Il existe plusieurs technologies pour implémenter la plateforme. Dans le but d’identifier la technologie la plus réactive et qui nous permet d’avoir le plus de contrôle sur la temporalité des évènements d’affichage et sur la mise à jour des données, nous avons procédé à des tests de performance. Les choix ont été guidés par les critères de rapidité et de flexibilité.
Décisions par rapport à nos critères
Pour valider notre choix de technologie web comme base de notre plateforme d’expériences, nous avons d’abord procédé à un test de performance, comparant une petite application développée avec Metal (l’API de rendu 3D sous Mac OS X, OpenGL n’est plus supporté depuis Mac OS X Mojave) et la même, développée avec WebGL.
Portabilité et délai minimum
Contexte
Une application développée en WebGL est portable, ce qui permet de faire des tests dans des conditions les plus réalistes possibles. Cependant, cette portabilité vient à un prix, celui d’une performance moindre par rapport à un programme natif. Il a donc fallu faire un compromis. Pour cela, nous avons donc d’abord comparé une application native avec une application web identique. Le protocole de test est une variante du premier test (Click) utilisé pour comparer les différentes librairies WebGL, que nous verrons dans la prochaine partie. Pour étudier la latence de pointage entre le mouvement de la souris et la mise à jour de l’écran, l’approche classique est de positionner une caméra haute fréquence devant l’ordinateur, filmant l’écran et la souris. La caméra enregistre les actions faites avec la souris et l’état de l’écran en même temps. Une fois l’enregistrement fini, on visionne la vidéo frame par frame et on identifie le début d’un évènement de la souris, et le moment où l’écran est mis à jour. On obtient ainsi le temps de latence. Casiez et al. ont proposé une autre méthode, plus pratique et cyclique, où ce qui est affiché à l’écran contrôle directement les mouvements de la souris, et retransmet ces mouvements. Pour cela, il suffit de poser la souris sur l’écran, et d’afficher à l’écran un motif facile à identifier pour la souris. En suite, on procède en commençant cette fois-ci par la mise à jour de l’écran. C’est la mise à jour de l’écran qui, détectée par la caméra de la souris, va faire croire à celle-ci qu’elle a bougé. La souris va donc envoyer un évènement de déplacement de souris, reçu par l’ordinateur. L’ordinateur a déclenché le début du cycle et reçoit l’évènement de la part de la souris à la fin de celui-ci. Il peut donc lui même calculer immédiatement (pas de traitement de données comme le visionage de vidéo) le temps de latence entre évènement d’un clique souris et affichage à l’écran. De plus, cette méthode peut être répétée pour obtenir plus de valeurs de latence, permettant de voir sa constance par exemple. Aussi, cela permet d’éliminer tout paramètre extérieur pouvant jouer dans le calcul de latence (CASIEZ et al., 2015).
Dans notre cas, nous nous intéressons exclusivement au temps de réaction de l’application à un évènement souris.
C’est pourquoi nous avons remplacé la partie impliquant une souris par une application qui simule le comportement d’une souris et peut lire l’écran2.2. On aura ainsi la possibilité de contrôler précisément quand et quel évènement sera envoyé, et quel mise à jour est attendue à l’écran. On désignera cette application comme le générateur d’évènements. Un paramètre limitant la vitesse de réaction d’une application est la fréquence de balayage de l’écran, ralentissant les échanges entre applications. Nous nous sommes basé sur une fréquence fixée à 60, étant celle des moniteurs que nous utilisons pour ces tests, et la fréquence la plus répandue en ce moment. L’expérience que nous avons utilisé pour comparer la réactivité d’une application native et une application WebGL suit le schéma de cycle, où l’on a deux parties distinctes échangeant des informations à travers des canaux d’entrée et de sortie. Ces informations sont interceptées par le générateur d’évènements, ce qui supprime le besoin de contrôler ces entrées et sorties depuis l’extérieur de l’ordinateur. Le principe est d’alterner entre deux états, permettant de faire autant de cycles que nécessaire. Le premier état est déclenché par l’appui sur le bouton gauche de la souris. À ce moment, lorsque l’application reçoit l’évènement de pression du bouton, elle doit colorer une surface en vert. Le générateur d’évènement, ayant généré l’évènement de pression et détectant le moment où la surface devient vert, peut calculer le temps mit par l’application pour réagir. Le second état correspond au relâchement du bouton, où l’application doit peindre la surface en bleu. Nous avons décidé d’enregistrer également les moments où l’application testée reçoit et a terminé sa procédure de mise à jour. Pour pouvoir comparer les temps obtenus par le générateur d’évènements et par l’application testée, il faut avoir une unité de temps commune. Nous avons donc choisi d’utiliser le nombre de millisecondes depuis l’époque UN*X. Avec ce simple test de réaction, on peut obtenir une idée de la différence de latence introduite par la technologie sous jacente.
Comparaison
En étudiant les résultats, il est clair que la vitesse de balayage de l’écran est inférieure aux temps de réaction des applications. On obtient ainsi en fin de compte des résultats très proches. Si l’on étudie les valeurs en excluant le passage par l’affichage, on remarque que la version native est plus rapide. Cependant, à ces vitesses, une grande quantité de facteurs commencent à avoir une importance non négligeable (tel par exemple les choix de l’ordonnanceur du noyau). Ces facteurs n’étant pas contrôlables, il n’est pas très intéressant, ni utile, d’essayer d’obtenir des valeurs plus précises, celles-ci étant par conséquent fortement bruitées. Ces résultats nous ont confortés sur ce que l’on peut atteindre comme performance en WebGL. Il reste maintenant à tester la performance de WebGL dans des cas plus complexes et plus réalistes. Nous souhaitions utiliser une librairie graphique basée sur WebGL, pour pouvoir bénéficier des différents outils mis à disposition, ainsi que leur structure que l’on viendrait augmenter de différents outils de contrôle de temps et de création d’expériences. C’est ce que l’on a donc fait ensuite. Nous avons donc fait un choix de librairies graphiques correspondant à nos attentes, et nous les avons testées dans des cas plus complexes, pour étudier leur performances dans différents cas de figure, et les comparer au cas simple précédemment étudié.
Choix d’une librairie WebGL
Il existe une très grande quantité de librairies graphiques utilisant WebGL. Nous avons ainsi par exemple une liste provenant du site de Khronos , de Wikipedia et deux autres listes . Le nombre de librairies existant est considérable. Certaines librairies avaient des buts très différents des nôtres se spécialisaient dans des fonctionnalités qui ne nous seront pas utiles (particules, calculs mathématiques), ce qui a permis un premier élagage. De plus, certaines librairies se basaient sur d’autres librairies. Nous n’avons gardé que les librairies de plus bas niveau. Après quelques tests de démonstrations et de recherches, nous avons choisi trois librairies avec le plus de potentiel parmi toutes celles que l’on a pu tester ou qui ont une notoriété. Ces librairies sont PixiJS, ThreeJS et TwoJS.
— PixiJS : Pour l’accent mis sur la 2D et ses démonstrations performantes
— ThreeJS : Pour ses démonstrations performantes
— TwoJS : Pour l’accent mis sur la 2D .
Ces trois librairies offrent différents outils pour créer des graphismes, et permettent également d’utiliser d’autres contextes comme un rendu SVG ou l’utilisation directe du canvas. En termes d’outils, nous avons retenu la classe Mesh pour ThreeJS, la classe Rectangle pour TwoJS, et les classes Graphics et Sprite pour PixiJS. On précisera par la suite la classe utilisée lorsqu’il s’agit de PixiJS. Au sujet des contextes utilisés, le principe de SVG est de décrire (à l’aide de code en XML) les formes à dessiner, qui seront dessinées par le moteur de rendu web (le navigateur) et mises à jour si l’on zoom la page par exemple. Le Canvas est en quelque sorte une grande zone dans laquelle les formes sont tracées, et le résultat est une texture générée par le processeur affichée à l’écran. WebGL est un moyen d’utiliser la carte graphique pour générer cette texture. Ainsi, l’élément HTML affichant le résultat de WebGL est une balise Canvas, mais tout le rendu de l’image est fait par WebGL. Nous avons choisi quelques unes des manières de créer des graphismes, selon l’implémentation de celles-ci, et avons testé tous les contextes différents. Le test de ceux-ci (WebGL, Canvas et SVG si disponible) permet de confirmer, ou d’infirmer, le choix d’utiliser WebGL comme technologie pour notre plateforme. Enfin, une version codée en WebGL, sans librairie, sera également testée, faisant office de témoin.
Tests de performance
On a implémenté deux tests avec chacune des librairies (ainsi que la version témoin). Cela nous permet de tester la réponse des librairies en fonction de différents évènements déclencheurs et différentes tâches à accomplir. Le premier test est basé sur le même principe que le test précédent, où l’évènement déclencheur est la pression du bouton gauche de la souris, et où l’application change la couleur de la scène. Cependant, on ajoute à la scène (jusqu’ici vide) une grille de carrés changeant de couleur de la même manière que l’arrière-plan. Cela permet de faire travailler la librairie et d’avoir un moyen de faire varier la complexité des tâches. Ce test est désigné par Click par la suite. Le second a pour évènement déclencheur le déplacement de la souris, et dès qu’un tel évènement est détecté, la librairie devra déplacer la grille de manière à suivre le curseur. Ce test est nommé Move.
Paramètres de l’expérience
Nous avons donc testé ces trois librairies dans conditions et avec différents paramètres, dans le but de trouver la librairie ayant une latence la plus faible, quelque soit l’activité du système alentour, la tâche qu’elle doit accomplir et les types d’évènements qu’elle reçoit. Pour cela, nous avons fait varier :
— Librairie utilisée : PixiJS avec Graphics, PixiJS avec Sprites, ThreeJS, TwoJS, témoin
— Contexte utilisé : WebGL, Canvas, SVG
— Type de test : Click, Move
— Complexité de la tâche à accomplir : Densité de la grille 20*10 jusqu’à 260*130
— Nombre de processus en arrière-plan : 1, 2, 3
En ce qui concerne la gestion des processus en arrière-plan, lors du lancement des tests, un minimum d’applications autres est en train de tourner, et nous allons ajouter au fur et à mesure des tests de plus en plus de processus « yes », ce processus ayant une consommation régulière de processeur. Cela nous permet de simuler le cas où l’application tourne dans des conditions difficiles, avec un processeur peu disponible. Chaque cas de figure sera fait 200 fois de suite. On en extraira la moyenne et un intervalle de confiance à 95%. Nous avons établi un protocole de test et implémenté les outils nécessaires pour mener ces tests.
Protocole d’évaluation
L’évaluation se base sur le temps mis par une librairie pour mettre à jour l’affichage, en fonction d’un évènement. Tous les tests de librairie ont été menés sur un MacBook Pro 13-pouces de 2017 :
— Processeur : 2.3GHz Intel Core i5
— Memoire : 8GB 2133MHz LPDDR3
— Graphismes : Intel Iris Plus Graphics 640 1536MB
— Système d’exploitation : MacOS Mojave Version 10.14.5 .
|
Table des matières
1 Introduction
1.1 Mises à jour gênantes de l’interface
1.1.1 Divergences entre intention et résultat
1.2 Mise en place d’une plateforme d’étude des interactions graphiques
1.2.1 Un environnement d’interaction contrôlé
1.2.2 Test de réaction lors du pointage
2 Étude de librairies WebGL pour la plateforme et d’autres projets
2.1 Décisions par rapport à nos critères
2.1.1 Portabilité et délai minimum
Contexte
Comparaison
2.1.2 Choix d’une librairie WebGL
2.2 Tests de performance
Paramètres de l’expérience
2.2.1 Protocole d’évaluation
Données enregistrées
2.2.2 Implémentation des outils de test
Pour un cas de figure
Pour toute l’évaluation
2.3 Résultats
2.3.1 Données
Faible densité
Forte densité
2.3.2 Interprétation
Divergences entre librairies et techniques
Choix final de la librairie
3 Première itération sur la librairie pour une première expérience
3.1 Stop Signal
3.1.1 Principe
3.1.2 Apport du pointage
3.2 Plateforme d’expérience
3.2.1 Buts de la plateforme
3.2.2 Structure
3.3 Expérience intermédiaire
3.3.1 Buts de l’expérience
3.3.2 Protocole de l’expérience
Déroulement
3.3.3 Mise en Œuvre de l’expérience
Logs et réaction
Fin d’un bloc et fin de l’expérience
3.3.4 État actuel de l’expérience
4 Retour sur le stage et perspective à venir
4.1 Compléments aux tâches menées
4.2 Apports, contretemps et solutions
4.3 Travaux futurs
Bibliographie
Télécharger le rapport complet
