IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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

Ce tutoriel décrit des outils et modalités de mesure, analyse et optimisation du fonctionnement des applications sur dispositifs tactiles Windows.

N'hésitez pas à donner votre avis par rapport à cet article : 4 commentaires Donner une note à l´article (4)

Article lu   fois.

Les quatre auteurs et traducteur

Voir la liste des auteurs

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

L'expérience utilisateur (UX) est aujourd'hui un moteur de changement pour les produits. Alors que les autres caractéristiques sont importantes dans les fonctionnalités d'un dispositif, aucun ne peut surmonter un manque de réponse perçu ou réel et la facilité d'utilisation de l'interface tactile. Depuis l'introduction de Windows 8, les gestes tactiles sont devenus un moyen principal d'interaction avec tablettes, téléphones et appareils Ultrabook™ sous Windows. L'utilité de ces systèmes repose en partie sur la façon dont l'interaction tactile améliore l'expérience utilisateur (UX) et — par extension — comment la qualité de l'UX est influencée par la vitesse et la réactivité de l'interface tactile.

Le temps de réponse d'une entrée tactile est la latence entre le moment où les utilisateurs commencent à déplacer leurs doigts pour effectuer des gestes tactiles et le moment où l'application fournit une mise à jour visuelle qu'ils attendent en réponse aux gestes effectués. La réponse au toucher est mesurée en intervalles de temps très petits (100-500 ms). Pour obtenir la meilleure UX, il est important d'identifier et d'optimiser les zones de réponse au toucher à faible performance.

L'activation de l'interaction tactile pour les applications Windows est un tout nouveau jeu de balle entre évaluation, analyse et optimisation. Une hypothèse qui n'est pas toujours vraie, c'est que si une application met à jour constamment une scène, elle répondra rapidement au geste tactile de l'utilisateur. Cet article présente des façons de mesurer la réponse au toucher, des méthodes d'analyse pour l'optimisation tactile sur l'architecture Intel® (IA) et la combinaison d'outils nécessaires pour comprendre les problèmes liés à la réponse tactile.

En plus du temps de réponse au geste tactile, l'utilisation des ressources de l'ordinateur et la vie de la batterie sont des facteurs très importants impactant l'UX. Cet article décrit deux applications qui rencontrent des problèmes tels que des temps de réponse prolongés ou l'absence de réponse au toucher et une forte consommation d'énergie, qui sont tous les deux essentiels à la performance de l'application et à l'UX. Nous discuterons ensuite de comment optimiser ces applications pour résoudre les problèmes.

II. Pourquoi est-il important de mettre en œuvre une bonne UX tactile ?

Les dispositifs Ultrabook et les tablettes connaissent une adoption croissante, et l'interaction tactile est l'un des piliers essentiels pour fournir une bonne expérience utilisateur (UX). Les périphériques tactiles sont partout, des téléphones, tablettes et Ultrabooks aux dispositifs tout-en-un (AIOAll In Ones), qui sont des PC de bureau avec tour intégrée à l'arrière de l'écran. Gartner, une société de recherche informatique, prévoit que d'ici 2015 plus de 50 % des PC achetés pour les utilisateurs de moins de 15 ans auront des écrans tactiles[1].

Image non disponible
Figure 1. Le rôle des logiciels dans la pile du tactile

Avec Windows 8, Microsoft a créé le Windows Store, qui agit comme un espace axé sur le tactile, permettant aux développeurs de publier leurs applications et aux consommateurs de les acheter. Si une application a une latence notable aux gestes tactiles de l'utilisateur, l'application peut être faiblement évaluée, ce qui affectera sans aucun doute ses ventes.

La figure 1 montre le rôle critique du logiciel et des pilotes dans la réactivité tactile où trois des cinq couches appartiennent à la pile logicielle (environ 60 %). La faible réactivité au toucher est généralement un problème dans la pile logicielle.

III. Gestion du tactile

Les applications de bureau Windows ont trois moyens de prendre en charge la saisie et les gestes tactiles. Pour bien comprendre l'utilisation de ces API tactiles, veuillez lire « À propos des messages et des files d'attente » [7]. Les messages WM_GESTURE et WM_TOUCH sont rétrocompatibles avec Windows 7, tandis que les messages WM_POINTER ne le sont pas. Chaque message comporte des avantages et des inconvénients. WM_POINTER est le plus simple à mettre en œuvre, mais fournit la moindre quantité de contrôle. WM_TOUCH nécessite la plus grande quantité de code, mais permet un contrôle très affiné, et WM_GESTURE est équilibré. De nombreuses approches peuvent être utilisées pour prendre en charge l'interaction tactile dans les applications du Windows Store, de la classe GestureRecognizer qui gère les entrées tactiles et les manipulations jusqu'à l'utilisation des API DirectManipulation qui ont été introduites dans Windows 8.1.

IV. La prime d'économie d'énergie par optimisation tactile

L'énergie est un autre pilier important de la garantie d'une bonne expérience utilisateur. La convivialité d'une application est influencée par l'énergie qu'elle consomme et la façon dont cela impacte la vie de la batterie. Si l'application consomme rapidement l'énergie, les utilisateurs seront réticents à l'exécuter. La consommation élevée d'énergie résulte généralement d'un usage intensif des ressources du système, par exemple, du CPU, GPU et même des périphériques de stockage qui effectuent un travail inutile. Les études de cas ci-dessous illustrent ces problèmes et mettent en évidence un effet secondaire observé souvent lors de l'optimisation des capacités de traitement tactile, qui réduit la consommation d'énergie de l'application. Cet effet secondaire de réduction de la consommation d'énergie est ce que nous appelons la « prime d'économie d'énergie ».

V. Outils Windows pour l'analyse des capacités tactiles

De nombreux outils peuvent vous aider à optimiser vos applications tactiles Windows. Il est essentiel de comprendre l'utilisation de chaque outil de mesure et d'analyse pour repérer les problèmes liés à la réponse au toucher. Ci-dessous se trouvent de brèves descriptions des outils, leurs utilisations prévues et la pertinence des aspects particuliers de l'analyse de l'interaction tactile.

V-A. Outils de mesure

  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.

V-B. Outils d'analyse

  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.

V-C. Questions à poser lors de l'utilisation de ces outils

  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.

VI. Études de cas

Pour ces études de cas, le procédé de la caméra à haute résolution a été utilisé pour obtenir un temps de réponse moyen d'environ 200 ms. Dans ces contextes, les applications n'avaient pas seulement une réponse tactile lente, mais souvent elles ont complètement échoué à répondre à un geste tactile.

VII. Une application de jeu multiutilisateur, multitactile avec faible réponse au toucher

VII-A. Énoncé du problème

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.

VII-B. Utiliser les outils pour identifier les problèmes

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.

Image non disponible
Figure 2. Application au ralenti, utilisation du processeur à 100 %

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

Image non disponible
Figure 3 : Application au ralenti Consommation CPU et GPU en watts

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.

Image non disponible
Image non disponible
Figure 4. Captures d'écran des sauvegardes de files d'attente GPU/CPU par l'outil GPUView

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.

Image non disponible
Figure 5 : La pile d'appels de l'application

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.

Image non disponible
Figure 6. La méthode Tick du jeu modifiant la résolution de l'horloge système

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.

VII-C. Résultat final

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.

Image non disponible
Figure 7. Utilisation optimisée du CPU par l'application

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.

Image non disponible
Figure 8. Activité optimisée de la file CPU et GPU de l'application

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.

VIII. Un jeu 3D avec perte de réponse tactile

VIII-A. Énoncé du problème

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.

VIII-B. Utiliser les outils pour identifier les problèmes

  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.

    Image non disponible
    Figure 9. Marquer les actions tactiles avec réponse et les actions tactiles sans aucune réponse

    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.

    Image non disponible
    Figure 10. Piles d'appels des actions tactiles avec réponse vs actions sans réponse

    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).
Image non disponible
Figure 11. Traitement de la pile d'appels des messages de la mauvaise UX

VIII-C. Résultat final

  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.

IX. Conclusion

L'optimisation tactile est essentielle et de nombreux outils de mesure et analyse sont disponibles. N'oubliez pas d'avoir un point de référence auquel vous pouvez comparer les données que vous avez recueillies pendant l'exécution de votre application. Regardez les différences entre les données obtenues lorsque l'application est tout simplement en cours d'exécution et les données obtenues en effectuant des gestes tactiles. Comparez les comportements de l'application lorsqu'elle répond à un geste tactile et quand elle ne le fait pas.

L'hypothèse — selon laquelle une application mettant à jour constamment une scène répondra rapidement au geste tactile de l'utilisateur — n'est pas toujours vraie. Une scène devrait être mise à jour lorsque cela est nécessaire, afin de préserver les ressources système qui permettent de répondre rapidement à un geste tactile lorsqu'il se produit. Souvent, les mises à jour inutiles d'une scène pour des animations sans importance déclenchent la sauvegarde des files d'attente des messages Windows, du CPU ou du GPU, ce qui peut entraîner ensuite des retards dans le déroulement d'une réponse visuelle au toucher de l'utilisateur.

X. Vidéos complémentaires (en anglais)

XI. Ressources

XI-A. Références

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

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2015 Thomas Pantel. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.