Mesure du toucher sur une surface tactile, analyse et optimisation pour les applications Windows

1. Mesurer le temps de réponse à l'aide d'une caméra à haute résolution ; enregistrez une vidéo des interactions tactiles et faites défiler manuellement image par image pour obtenir les temps de réponse.

2. Windows PerfMon, l'analyseur de performances Windows :

   1. Inclus dans Windows pour regarder les statistiques CPU et du système ;
   2. Cet outil collecte à un deuxième niveau de granularité et donne un aperçu du comportement du système lorsque l'application est en cours d'exécution.
3. Intel® Power Gadget : recueille les indicateurs de puissance/énergie tels que la consommation d'énergie du paquetage (CPU et GPU).

4. Enregistreur de performances de Windows (WPR) :

   1. Fourni avec Windows 8 / 8,1 ADK ;
   2. WPR possède une interface utilisateur (WPRUI) qui permet d'effectuer des traces qui collectent des paramètres système spécifiques comme l'utilisation du processeur, les commit en mémoire virtuelle, la consommation d'énergie, etc. 

5. FRAPS :

   1. Indique le taux de rendu d'une application (FPS) et ne fonctionne que sur des applications de bureau ;
   2. Bien que le site Web dise qu'il ne prend en charge que des versions jusqu'à Windows 7, vous pouvez l'utiliser sur des applications de bureau Windows 8/8.1.

1. Analyseur de performances de Windows (WPA) :

   1. Fourni avec Windows 8 / 8,1 ADK ;
   2. WPA est utilisé pour charger le fichier .etl généré par WPR de sorte qu'une analyse en profondeur puisse être effectuée.

2. Intel® VTune ™ Amplificateur XE 2013 :

   1. Permet aux développeurs de comprendre quelles fonctions/modules sont plus chronophages ;
   2. Fournit une vue détaillée de l'ordonnancement des fils d'exécution.
3. Intel® Analyseur de goulot d'étranglement de performances (PBA) : fournit des capacités avancées d'analyse pour les optimisations de réactivité.
4. GPUView : fourni avec Windows 8 / 8,1 ADK, offre un regard en profondeur sur ce qui se passe entre la file d'attente du contexte CPU et la file d'attente matérielle GPU. Utilisez l'option de trace WPRUI « activité GPU » lors de la collecte de ces informations.
5. Intel® Analyseur de performance graphique (Intel® GPA) : xFournit des informations sur l'activité graphique du système, y compris le nombre d'images par seconde.

1. Intel Power Gadget signale-t-il un paquetage (CPU et GPU) dont la consommation d'énergie est beaucoup plus grande que la ligne de base ?

2. Est-ce que l'analyseur de performances Windows met en évidence une utilisation élevée du processeur ?

   1. Est-ce que les scènes ont des mises à jour visuelles ?
   2. S'il y a des pics d'utilisation du processeur, qu'est-ce qui se passe à l'écran ? Peut-être qu'une animation qui se produit toutes les trois secondes provoque l'augmentation de l'utilisation du processeur toutes les trois secondes.
3. GPUView montre-t-il si la file d'attente CPU / GPU est sauvegardée ?
4. Que montre l'analyseur de goulot d'étranglement de performances Intel dans la vue de la chronologie ? Filtrez sur le module consommant le plus de temps CPU et regardez quelle activité module/fil d'exécution se produit.
5. Est-ce que l'application modifie la résolution du cycle d'horloge du système de 15,6 ms (valeur par défaut Windows) à une valeur plus petite ? Si l'application modifie la résolution du cycle d'horloge du système à une valeur inférieure, c'est-à-dire 1 ms, elle effectuera trop souvent des appels Update et Draw, ce qui peut entraîner la sauvegarde de la file d'attente du contexte CPU et/ou de la file d'attente GPU.

Maintenant, regardons comment ces outils ont été utilisés pour optimiser les deux applications et répondre à certaines des questions ci-dessus.

Cette application de bureau Windows avait des délais de latence autour de ~ 170 ms. Mais pire encore, l'application échouait souvent à fournir une réponse (aucune mise à jour visuelle après le geste tactile). Comme c'était un jeu de sport, ces problèmes de réponse provoquaient souvent des scores peu représentatifs.

Le premier outil que nous avons utilisé était Windows Perfmon, car il recueille des données qui fournissent un aperçu de ce qui se passe sur le système lorsque l'application est en cours d'exécution. Regarder l'utilisation des ressources par l'application en l'absence des gestes tactiles donne une idée de ce qui provoque la plus grande partie du goulot d'étranglement quand un geste tactile se produit. Nous pouvions voir ici si certaines ressources — comme l'utilisation du processeur, le taux de commutation de contexte, le taux d'interruption, etc. — étaient déjà au maximum (100 % d'utilisation) ou au-dessus des valeurs de seuil obtenues lors l'analyse précédente des charges de travail.

La figure 2 montre qu'un seul cœur CPU (processeur 0) est utilisé pendant 100 % du temps, ce qui signifie que cette application simple cœur était liée au processeur lors de l'actualisation d'une scène visuellement immuable.

L'outil Intel Power Gadget a été utilisé pour avoir une idée de l'impact causé par l'application en utilisant un seul cœur CPU à 100 % du temps. Nous avons exécuté l'invite de commande en tant qu'administrateur, navigué vers le répertoire d'installation, et saisi :

PowerLog3.0.exe -duration <duration to run for in seconds> -file <log_file.csv>

Après l'exécution de la commande, nous avons tapé le nom du log_file.csv et pressé Entrée. La figure 3 montre la consommation d'énergie du paquetage (CPU et GPU) du système alors que l'application était en cours d'exécution et ne traitait aucune interaction tactile. L'axe des abscisses représente le taux d'échantillonnage de la lecture des MSR d'énergie et l'axe des ordonnées est la puissance du processeur en watts [3].

Le même comportement s'est produit lorsque des gestes tactiles ont été effectués, comme indiqué dans les diagrammes d'utilisation du processeur, même lorsque la puissance est restée presque identique avec et sans interactions tactiles. Cela indique clairement que quelque chose consommait toutes les ressources, ce qui rend difficile la réponse au toucher. La consommation d'énergie du système lorsque l'application n'était pas en cours d'exécution était d'environ 2,5 W, ce qui signifiait que l'application a provoqué une augmentation de la consommation de 9 W. Qu'est-ce qu'était à l'origine de cette augmentation de 9 W de la consommation du CPU et du GPU ?

Ensuite, Intel GPA a été utilisé lorsqu'on a signalé une fréquence de rendu d'environ 350 images par seconde (FPS) alors que l'application ne gérait aucun geste tactile et d'environ 210 FPS lorsque des gestes tactiles ont été effectués. Bien qu'il fasse constamment débat, l'œil humain ne peut pas distinguer généralement la différence entre un rendu à 60 FPS et un rendu à 120 FPS. Cela signifie que les utilisateurs verraient sur l'écran à 120 FPS les mêmes mises à jour visuelles que si l'application rendait à 60 FPS.

Puis, GPUView a été utilisé et a montré que cette fréquence de rendu élevée a provoqué le remplissage de la file d'attente GPU lorsque l'application essayait de soumettre le travail au pipeline GPU aussi vite que possible. La figure 4 montre des rangées de paquets à doubles chevrons, qui indiquent un paquet présent prêt à être affiché à l'écran. Cette activité avait lieu lorsque l'application affichait un écran sans aucune mise à jour visuelle.

Quelle était la cause de l'utilisation du processeur à 100 % et de la sauvegarde des files d'attente CPU/GPU ?

WPRUI a été utilisé ensuite et la seule option de traçage sélectionnée était l'utilisation du processeur pour réduire la surcharge causée par l'outil. Lors de la collecte sur les scénarios d'inactivité, prenez en considération la surcharge causée par l'outil lui-même. À ce stade, nous savions que l'application faisait sauvegarder les files d'attente CPU/GPU, alors qu'est-ce qui a été appelé avant le module graphique ? En inspectant la pile d'appels de l'application au module graphique, nous avons trouvé quelques indices quant à ce qui a été appelé, expliquant ce travail inutile.

L'inspection de la pile d'appels de la figure 5 a montré l'appel d'une méthode Game::Tick peu avant qu'un appel D3D9 Present ait lieu, ce qui a finalement conduit au module graphique igdumd32.dll. Cette méthode Game::Tick réglait involontairement la résolution du cycle d'horloge du système à 1 ms, contre 15,6 ms (valeur par défaut de Windows). Voir la Figure 6.

Ainsi, toutes les 1 ms l'application effectuait des appels Update et Draw puisque Game::Tick était appelée. L'appel de ces méthodes chaque milliseconde signifie également que le CPU se réveille souvent sans entrer dans des états de sommeil plus profond (C-States) et le GPU est plus occupé que nécessaire.

Des API sont disponibles pour assurer que l'application ne modifie pas la résolution de l'horloge du système et que l'application soit synchronisée avec Vsync. Après l'utilisation de ces types d'API, le CPU ne dépensait plus 100 % du temps d'exécution sur des appels Update et Draw.

Puisque le CPU n'exécutait plus des calculs Update inutiles et des appels Draw à chaque milliseconde, la file d'attente du contexte CPU et la file d'attente du GPU ne sont plus sauvegardées. La capture d'écran sur la figure 8 montre le travail soumis à 60 FPS puisque le taux de rafraîchissement de l'écran est de 60 Hz.

La fréquence de rendu de l'application a été désormais plafonnée à 60 FPS puisqu'un paquet présent est soumis à tous les Vsync sur un moniteur avec un taux de rafraîchissement de 60 Hz. En optimisant la consommation des ressources par l'application dans un scénario d'inactivité (aucun changement visuel à l'écran et aucun geste tactile traité), les réponses au toucher étaient plus rapides et plus lisses. Le temps moyen de réponse tactile de l'application optimisée était d'environ 110 ms, là où auparavant il était en moyenne d'environ 170 ms et des entrées tactiles n'étaient plus perdues (pas de réponse de l'application).

Comme un avantage supplémentaire (prime pour l'économie d'énergie), la consommation d'énergie du système a été réduite d'environ 8,5 W. Maintenant, les utilisateurs pourront exécuter l'application sur leur appareil Windows mobile favori pour une période de temps plus longue avant d'avoir à recharger la batterie.

En résumé, le comportement d'inactivité de l'application peut amener l'application à inonder le pipeline de gestion tactile. Avec la version optimisée, l'application avait plus de place pour gérer des gestes tactiles supplémentaires, ce qui lui donne l'avantage d'une latence tactile diminuée.

Cette étude de cas est un jeu 3D gratuit fonctionnant sur le bureau Windows 8 qui utilise des messages WM_TOUCH pour gérer les entrées tactiles. Pour jouer, les utilisateurs touchent l'écran à différentes orientations afin qu'un avatar exécute différentes actions (comme sauter, glisser, s'accroupir, etc.). Si aucun geste tactile n'est effectué, l'avatar avance sur une trajectoire fixe.

Dans la version originale du jeu, lorsque deux types d'interactions tactiles ont été effectuées, l'avatar n'exécutait pas l'action attendue et continuait tout simplement à courir vers l'avant.

1. Lorsque deux actions tactiles ont été réalisées successivement, si l'intervalle de temps entre eux était trop petit, la deuxième action n'avait généralement aucune réponse.
2. Lorsque la distance d'une action tactile se déplaçant sur l'écran était trop courte, l'action n'avait généralement aucune réponse.

1. Isoler le problème. Déterminez si les problèmes de réponse tactile sont dus à l'application ou à la plate-forme (matériel / pilote / OS). La méthode recommandée ici c'est d'exécuter WPR, basculez vers l'application et effectuez un seul geste tactile à des moments précis au cours de la collecte de données pour montrer visuellement pendant l'analyse les événements tactiles et leurs durées, moments précis au cours de la collecte de données pour montrer visuellement pendant l'analyse les événements tactiles et leurs durées.

   

   Enregistrez manuellement les événements tactiles avec et sans réponse. Grâce à un processus qui permet de suivre l'enregistrement tactile, nous avons pu marquer le moment où le système d'exploitation a enregistré le contact en inspectant la pile d'appels pour les fonctions de traitement de message comme montré sur la figure 9 (les pointes violettes).

2. Comparez les piles d'appels des bonnes et mauvaises UX. Comparer divers aspects d'une action tactile qui reçoit une réponse (bonne UX) à une action sans aucune réponse (mauvaise UX) montrera souvent une différence entre les fonctions appelées par l'application.

   

   Les piles d'appels contenant FrameMove() ont été étudiées puisque cette fonction, comme son nom l'indique, fournit une mise à jour visuelle. Dans la pile des appels « Bonne UX », une fonction AvatarMovesToTheLeft :: FrameMove est appelée, tandis que dans la « Mauvaise UX » elle ne l'est pas (voir Figure 10).

3. Tracer les piles d'appels. En traçant la pile d'appels de la « Mauvaise UX », nous avons découvert où la chaîne d'appels était interrompue. Les fonctions Windows de traitement de messages ont été appelées, y compris PeekMessage, DispatchMessage et même la fonction WndProc du jeu. Cela a confirmé que toutes les entrées tactiles ont été reçues par la fonction de traitement de messages de l'application, mais les fonctions xxxSlideLeftState ou xxxSlideRightState qui définissent le mode de déplacement de l'avatar pour l'animation attendue n'ont pas été appelées (voir Figure 11).

1. La cause de la perte des touchers successifs rapides est que le toucher n'agit sur le jeu que si le mode de déplacement de l'avatar est dans l'état « Courir vers l'avant ». S'il est dans un autre état, l'entrée tactile sera abandonnée. Par exemple, après le premier geste tactile, l'état du mode de déplacement passe de « Courir vers l'avant » à « Glisser vers la droite ». Si le second toucher se produit juste avant que l'état ne redevienne « Courir vers l'avant », il sera abandonné. Le problème a été résolu en mettant en cache les messages tactiles pour un mode d'exécution approprié.
2. La cause de la perte du toucher court a été liée à la fonction WndProc du jeu. Le jeu a reconnu le geste tactile uniquement si sa longueur était de plus de 60 pixels logiques, ce qui explique pourquoi certains touchers courts ont été perdus. Pour la même résolution, 60 pixels logiques couvrent une distance physique plus longue sur l'écran d'un Ultrabook que sur l'écran d'un iPhone. Cela rend les touchers courts sur un jeu porté de la plate-forme iPhone sur Ultrabook plus susceptibles d'être perdus sur l'écran Ultrabook. La solution consistait à définir le seuil de la longueur du toucher basé sur la distance physique sur écran en points par pouce (DPIDots Per Inch) au lieu de pixels logiques.

En résumé, nous avons isolé les problèmes liés soit à l'application, soit à la plate-forme en comparant les appels à l'API de messages de Windows afin de déterminer si le système d'exploitation a enregistré le toucher et où. Ensuite, les piles d'appels appartenant aux gestes tactiles qui ont eu une réponse attendue (Bonne UX) et aux gestes sans réponse (Mauvaise UX) ont été comparées pour trouver les différences entre les fonctions qui ont été appelées. Enfin, le traitement des messages de la pile d'appels du jeu pour une entrée tactile perdue a été tracé en amont pour trouver l'endroit où s'est produite l'interruption de la chaîne d'appels. Le début de la trace était à partir des fonctions qui ont été appelées dans la pile d'appels de la bonne UX, mais pas dans la pile d'appels de la mauvaise UX.

[1] Fiering, Leslie. Gartner Says More Than 50 Percent of PCs Purchased for Users Under the Age of 15 Will Have Touchscreens by 2015. Gartner, 7 Apr. 2010. Web. 03 Mar. 2014.

[2] Chabukswar, Rajshree, Mike Chynoweth, and Erik Niemeyer. Intel® Performance Bottleneck Analyzer. Intel Corporation, 4 Aug. 2011. Web. 12 Feb. 2014.

[3] Seung-Woo Kim, Joseph Jin-Sung Lee, Vardhan Dugar, Jun De Vega. Intel® Power Gadget. Intel Corporation, 7 Jan. 2014. Web. 25 March 2014.

[4] Freeman, Jeffrey M. « Intel® Graphics Performance Analyzers (Intel® GPA) FAQ » Intel Corporation, 17 Dec. 2013. Web. 25 Mar. 2014.

[5] H, Victor. « iPhones Score Highest Touch Responsiveness, More than Twice as Responsive as Android and Windows Phone Devices » Phone Arena. Phonearena, 01 Oct. 2013. Web. 26 Mar. 2014.

[6] « Windows Assessment and Deployment Kit (Windows ADK) » Microsoft Corporation, 2 April. 2014. Web. 3 April 2014.

[7] « About Messages and Message Queues » Microsoft Corporation, 24 Jan. 2012. Web. 26 Mar. 2014.

[8] Intel® VTune Amplifier XE 2014. Intel Corporation, 6 Mar. 2014. Web. 3 April 2014.

[9] Fraps 3.5.99. Fraps, 26 Feb. 2013. Web. 3 April 2014.