Archives de catégorie : UI

[Tips] Changer la culture de tous les threads en 1 ligne de code

Avec ASP.net, il est possible de définir globalement la culture via le fichier de configuration web.config et les attributs uiCulture et culture de la balise globalization :

<globalization uiCulture="fr-FR" culture="fr-FR"/>

Seul problème, cette configuration ne s’applique pas à l’ensemble des threads créés manuellement depuis les pages/handlers/modules.

En effet, si on créé un thread depuis une page, la culture par défaut de ce thread sera la culture du système sur lequel l’application est installée.

Avant .net 4.5, il était donc nécessaire de changer la culture manuellement à chaque création de thread.

Depuis .net 4.5, il est possible de définir une culture par défaut pour tous les threads qui seront créés par votre application via la propriété statique DefaultThreadCurrentCulture de classe CultureInfo :

CultureInfo.DefaultThreadCurrentCulture = ci

ASP (.net) a un cycle de 6-7 ans

Comme annoncé par Scott Hanselman ASP.net 5 actuellement en RC (et annoncé comme étant “production ready) est renommé en ASP.net Core 1.0.

Le nommage rejoint ainsi celui de .NET Core et se distingue plus clairement d’ASP.net 4.6 en ne laissant pas supposer qu’il s’agit d’une mise à jour de cette version mais bien d’un nouveau produit.

Cela est maintenant bien plus clair et peut donc inquiéter les développeurs qui n’avaient pas encore assimilé ce saut technogique entre ASP.net 4.6 et l’ex ASP.net 5 : “Encore une nouvelle version, qu’il va falloir assimiler, encore des réécritures/refontes/migrations en vue”.

Oui, cela est tout à fait vrai, c’est bien un nouveau produit qui devrait prochainement être disponible en RT(M/W), mais les plus grosses ruptures ne sont pas si fréquentes que cela, si l’on analyse les versions 1.0 de chaque technologie de développement web proposée par Microsoft, on se retrouve avec un cycle plutôt stable de 6-7 ans :

image

Cela peut sembler être une vision un petit simpliste car plusieurs changements ont été apportés notamment entre les différentes versions d’ASP.net MVC mais est quand même représentatif des ruptures auxquelles nous avons eu droit pour le moment.

image

Ressources supplémentaires sur le développement d’applications métier (LOB) pour Windows 8 et WP8

Comme indiqué précedemment, j’ai eu l’opportunité de présenter une session sur le développement d’applications métier pour Windows 8 et Windows Phone 8 avec la précieuse aide d’Audrey Petit.

image

Nous avons évoqué une grande variété de sujets (Opportunités, Déploiement (via le Store ou déploiement privé), Ergonomie Modern UI, Stratégies, Transition vers ModernUI, etc.) et n’avons donc pas pu approfondir tous ces sujets en 1h.

En fonction des Q&A de fin de session, je vous propose donc une liste de ressources complémentaires qui vous permettra d’aller plus loin sur certains points.

Pour débuter cette liste de ressources, je vous propose en plus des différentes démonstrations que nous vous avons montré, un case study sur le développement d’applications métier pour Win8.

Du côté utilisateur, voici un post de blog indiquant comment Utiliser des applications d’entreprise avec Windows 8 [US]. La fonctionnalité est présentée dans le contexte “Bring your own device” mais correspond tout à fait à celle indiquée durant la session.

Du côté IT, pour le déploiement des applications via Intune et l’app portail d’entreprise vous pouvez consulter cette présentation très complète sur le déploiement d’applications d’entreprise pour Windows Phone [FR]

Si vous souhaitez une synthèse du processus de déploiement que nous avons décrit vous pouvez également consulter ce post ainsi que ce post rentrant plus dans le détail de Windows Intune.

Toujours sur Windows Intune, Channel9 propose une démo en vidéo du process de déploiement.

Nous avons également parlé des possibilités de déploiement via scripts, vous trouverez sur cette page la documentation sur ceux-ci mais également sur la suppression des applications comme demandé durant la session de Q&A.

A propos de la question sur la possibilité de créer des applications ASP.net avec le look ModernUI, vous trouverez ici un ensemble de ressources permettant d’y arriver avec présence des plugin jQuery que j’avais évoqué.

Et enfin pour confirmer ce que j’indiquais à propos de l’addin de storyboarding pour Powerpoint il vous faudra disposer de Visual Studio 2012 Test Professional, Premium ou encore Ultimate pour être capable d’en profiter :

image

image

ReMix 11

imageReMix 2011Comme indiqué dans les news de la semaine, Microsoft organisait hier le ReMix 11, version française et synthétique de l’évènement Mix 11 qui a eu lieu à Las Vegas il y a quelques semaines.

La matinée était destinée aux “décideurs Marketing” et n’en était pas moins intéressante même pour un profil “Techos” comme le mien.

Je ne vous parlerais donc pas des opportunités business apportées par les différentes technos présentées notamment dans le secteur du retail mais plutôt des éléments techniques que j’ai pu retenir.

Et j’ai retenu un point de cette matinée :

  • Le support inconditionnel d’HTML 5 et les attentes suscitées par ce standard

Que cela soit de la part de Microsoft ou des différents intervenants qui ont pu présenter leurs projets ou parler lors des tables rondes, tout le monde avait des attentes fortes sur HTML 5. Cela s’explique par la nécessité de disposer d’une norme unique et supportée par tout le monde (cross-browser et cross-device) afin de proposer un service simplement à destination de tous. Eric Cremer de Dailymotion résume bien la situation : alors que l’on parle beaucoup d’unification, nous sommes toujours (et de plus en plus) dans un monde très fragmenté. Entre les applications web qui doivent être compatibles multi-browser (Internet Explorer, FireFox, Google Chrome, Safari, etc.) et les applications riches (iPhone, Windows Phone 7, Android, etc.), fournir un service sur toutes les plates-formes coûte cher demande du temps pour toucher des utilisateurs qui sont souvent surévalués en nombre. Comme l’a indiqué Eric Cremer, les smartphones représentent 20% des téléphones, et les iPhone représentent 30% de ceux-ci. De quoi modérer les investissements vers ce type de plate-forme.

L’HTML représente donc le messie que tout le monde attend afin d’être capable de développer une application qui fournira un même service à tous les utilisateurs puisque supporté par tous les principaux browser et devices.

Nous avons eu d’ailleurs droit à plusieurs démonstrations sympathiques, d’un site Renault avec une expérience utilisateur riche rendue possible grâce à HTML 5 ou encore d’un CMS dont l’administration se fait (presque) sans BackOffice.

Une matinée intéressante même si je n’en retranscrit ici qu’une faible partie.

L’après-midi était elle destinée aux développeurs et aurait pu être commencée par David Rousset expliquant qu’HTML 5 ne serait pas le messie tant attendue par les marketeux du matin Sourire (même s’il s’en rapproche).

Celui-ci s’est efforcé de montrer les énormes progrès et même les innovations apportées par IE 9 en terme de respect de standards (tant d’un point de vue de l’affichage que des performances) et à ensuite présenté un état des lieux objectif de la situation actuelle à propos d’HTML 5 :

  • Tous les navigateurs (IE compris) n’implémentent pas encore l’intégralité de la myriade des standards qui tournent autour d’HTML 5.
  • Il est donc nécessaire de fournir des modes dégradés aux navigateurs moins avancés que les autres
  • Certaines parties du standards sont encore sujettes à modification
  • Les benchmarks sont du bullshit marketing (ça c’est pas nouveau…)
  • Il manque les outils de développement qui permettent de créer de vrais applications HTML 5, et cela donc coute très cher à développer à l’heure actuelle. (Mon principal reproche sur HTML 5 actuellement)

David Catuhe a quant à lui présenté les nouveautés de Silverlight 5 et Windows Phone 7.5 “Mango”. Il s’agissait de la présentation la plus technique et (donc ?) la plus intéressante puisque présentant des nouveautés que l’on avait pas vu jusqu’à présent (comme les nouveautés liées à au prochain émulateur de Windows Phone). Nous avons vu en vrac :

  • Le fait que Silverlight 5 sera peut-être PC only. J’espère sincèrement que cela ne sera pas le cas, mais la difficulté d’implémenter la couche 3D en cross-plateforme (alors que Flash le fait sans soucis sur Windows/Mac/Linux).
  • Un meilleur accès aux informations stockées par le téléphone (contacts, calendrier, etc.) sera proposée
  • De biens meilleures performances avec apparemment une exposition des contrôles “natifs” utilisés par Microsoft pour l’interface de Windows Phone dans Silverlight. Finis donc les problèmes de listbox qui rament alors qu’elles ne contiennent pas grand chose.
  • La mise à disposition d’un SQL Server CE
  • Des outils permettant d’émuler le GPS/boussole/gyroscope

Here is the slide with #WP7 new features - with Spatial Framework information on it by @Deltakosh at #remix11

Microsoft organisera d’ailleurs  un évènement le 1er Juin à propos de Mango afin de pouvoir découvrir toutes les nouveautés de cette version majeure de Windows Phone.

David a ensuite parlé des opportunités offertes par les technologies UI telles que WPF et Silverlight, et Kinect en terme d’ergonomie et comment en profiter pour créer des applications avec une UX sympa et ayant conscience de leur environnement.

En synthèse donc une bonne journée à laquelle j’ai pu assister de Pau tout en travaillant grâce au livestreaming qui était de bonne qualité.

unsecure

Le bug de conception de la PasswordBox

C’est en utilisant la PasswordBox récemment (et en réfléchissant un peu plus que d’habitude) que j’ai réalisé ce que contrôle avait un bug de conception lié à la sécurité.

En WPF, le contrôle expose deux propriétés liées à la gestion du mot de passe.

La propriété SecurePassword est une propriété en readonly qui renvoie le mot de passe stocké par la PasswordBox sous la forme d’une SecureString.

Le type SecureString est un type intéressant qui permet de stocker en mémoire une string de manière sécurisée. Cette chaine de caractères est en effet cryptée en mémoire via DPAPI et ne peut donc être lue en clair malgré le fait qu’elle réside en mémoire.

Pour définir la valeur d’une SecureString il est nécessaire de le remplir caractère par caractère grâce à la méthode AppendChar, et pour lire en clair la valeur stockée par une SecureString on doit allouer de la mémoire et y stocker la valeur en clair de la SecureString via un Marshal.SecureStringToBSTR (qui au passage ne respecte pas les conventions de nommage .net). Une fois lue, on peut ensuite faire un reset la zone mémoire qui contient la valeur en clair via la méthode ZeroFreeBSTR (qui ne respecte toujours pas les conventions de nommage .net).

On réduit ainsi fortement l’intervalle de temps où la chaine de caractères, dans notre cas le mot de passe, est en clair en mémoire.

La PasswordBox utilisant une SecureString en interne on pourrait donc se dire que ce contrôle est parfaitement sécurisé… si l’on évoquait pas la seconde propriété dédiée à la gestion du mot de passe : la propriété Password.

Cette propriété de type String permet de définir et récupérer le mot de passe stocké par la PasswordBox. Et qui dit type String dit, lisible comme de l’eau de roche via n’importe quel outil de type Snoop et consors :

Donc en résumé, la propriété Password devrait en réalité se nommer “UnSecurePassword” et la propriété SecurePassword est inutile. Pourquoi en effet stocker le mot de passe de manière sécurisé si on l’expose en même temps en clair ?

Vous allez me répondre que c’est simple, il faut bien que l’on soit capable de définir la valeur de la PasswordBox via une propriété qui ne soit pas en Readonly. Certes, mais en a-t-on vraiment besoin ?

Le contrôle n’a pour objectif que d’afficher des ●●●●●● et on se moque donc de savoir si les ●●●●●● représente le vrai mot de passe ou en réalité de simples espaces. La classe SecureString exposant une propriété Length on pourrait facilement avoir une représentation visuelle du mot de passe sans avoir à le stocker en clair en mémoire.

On disposerait ainsi d’un contrôle PasswordBox vraiment sécurisé et non pas d’une sécurité en carton.

Quand à l’implémentation d’un tel SecurePasswordBox, il pourrait bien faire l’objet d’un prochain article…

image

On peut se dire que l’équipe d’Internet Explorer 9 a gagné…

On peut se dire que l’équipe d’Internet Explorer 9 a gagné en constatant qu’aujourd’hui un bloggeur peut se permettre d’écrire un post intitulé “Why Internet Explorer will survive and Firefox won’t” sans être trop ridicule.

imageIl s’agit certes d’un point de vue subjectif, et d’un avis tranché, mais qui est défendu avec des arguments intéressants et valables.  Le post est très largement discutable (je ne suis d’ailleurs pas d’accord avec ce billet) mais il reste crédible.

Et cela n’aurait pas du tout été le cas encore hier… Le même auteur aurait eu la même crédibilité en écrivant l’exact contraire. Et je trouve que ce changement de situation est remarquable.

J’avais déjà bloggé à différentes reprises (Compte Rendu PDC 2010 et Les nouveautés d’IE 9) sur le fait que j’étais impressionné par le travail d’engineering réalisé par l’équipe d’Internet Explorer et même s’il reste des défauts non négligeables (j’y reviendrais ultérieurement via un autre post) , force est de constater que le résultat est de l’avis de toutes les personnes censées à la hauteur (voire au-dessus en ce qui concerne les performances) des autres principaux navigateurs du marché.

Il y a très clairement une part de stratégie dans tout cela, mais la concurrence y est également pour beaucoup. Tous les navigateurs ont exactement les mêmes objectifs : une performance maximale en utilisant si possible le GPU pour y arriver, le respect de standards n’existant pas encore (HTML 5, CSS 3), une ergonomie réétudiée d’un point de vue de la gestion des onglets et de la barre d’adresse (entre autres), et une simili intégration des applications web en applications “natives”. Au point que l’on peut ne plus trop voir la différence entre ceux-ci :

Loin de moi l’idée de dire qu’IE 9 est le meilleur des navigateurs, ce qui est sûr ce qu’avec la sortie d’IE 9, la disponibilité de Chrome 10, et la publication de 4 (!) versions majeures de Firefox,  c’est durant cette année 2011 que l’on devrait probablement voir se décider quels seront les leaders de ce marché !

image

Session Ergonomie aux TechDays 2011

Je viens de regarder la session “Changer la vie de vos utilisateurs en intégrant design et ergonomie” (étrange d’avoir un nom aussi long pour une session sur l’ergonomie…) d’un de mes ex-collègues Olivier Courtois de la société Bewise.

Cette session est très réussie tant au niveau de la forme (je n’en attendais pas moins de la part d’Olivier) que du fond.

Je vous invite donc à la visionner si vous vous intéressez de près ou de loin à ce sujet.

image

Suite à cette présentation, je me suis décidé à tester cette “conception centrée utilisateur” présentée dans cette session, sur le développement de ma prochaine fonctionnalité.

Je ne suis pas designer ni ergonome, je vais donc uniquement donner mon point de vue de développeur sur cette méthode de travail et pourquoi je me suis décidé à l’expérimenter.

L’objectif de débuter par la conception et la réalisation de l’interface utilisateur au lieu de débuter par la conception et l’écriture de code pour les couches sous-jacente est tout à fait pertinente puisqu’elle permet de se concentrer sur le principal acteur de votre application : l’utilisateur.

Celui-ci se moque éperdument de savoir si vous écrit du code ADO.net à la mano ou si vous avez utiliser le dernier ORM à la mode.

Les seuls interlocuteurs qui peuvent vous reprocher du code écrit avec les pieds et/ou non maintenable sont :

  • les développeurs de votre équipe qui vont potentiellement vous écharper d’avoir écrit du code en carton
  • vos responsables (chef de projet, n+1, etc.) qui verront d’un mauvais œil le fait qu’il soit nécessaire de passer 3 siècles à maintenir et faire évoluer une fonctionnalité qui certes est très bien d’un point de vue UI mais coute au final très cher en développement

Le fait de débuter par la création de l’UI présente les avantages suivants :

  • permet de faire des itérations de validation de la fonctionnalité d’un point de vue de son utilisation avant même de penser à l’implémentation technique sous-jacente.
  • Permet de ne pas bâcler l’UI et l’ergonomie. Si je dois mettre 5 jours à implémenter une fonctionnalité, et que je commence par la partie la plus technique, il y a des chances que le temps consacré à l’UI soit réduit, et que les solutions adoptées soient les solutions “au plus vite”
  • Permet d’éviter l’over-engineering. Si le développeur attaque débute par le développement de l’UI il y a de fortes chances qu’il n’est ensuite plus le temps de réfléchir à implémenter une solution technique inutilement complexe.

Il ne me reste plus qu’à expérimenter tout cela, que cela soit d’un point de vue du process (sketchs, itérations de validations, puis dév) que des outils (balsamiq, SketchFlow, etc.). Je ne manquerais pas de partager avec vous mes premiers retours à ce sujet !

Faites vraiment attention avec les BitmapEffect

Lors d’une session de profiling CPU effectué durant une session de test de l’application
sous TSE, je me suis rendu compte que l’application sur certaines sessions utilisateurs
essayait de pomper 100% du CPU. Et avec grande surprise, quand j’ai demandé aux testeurs
s’ils effectuaient des traitements longs et couteux, certains m’ont indiqué que non
pas du tout, ils étaient juste devant une fenêtre qui affichait une petite grille
avec quelques lignes.

Après vérification, la fenêtre était très simple, et lorsque l’on ouvre ou ferme la
fenêtre le CPU passe d’aux alentours de 0% à 100% alors qu’aucun traitement n’est
censé se dérouler. Bien évidemment le problème n’a pas été détecté jusqu’à présent
puisqu’utilisé ailleurs que dans une session TSE, ce comportement n’est pas reproductible.

On passe donc doucement aux choses sérieuses, et ne connaissant pas encore correctement
l’application sur laquelle je travaille, je lance Snoop afin de trouver le nom de
la fenêtre incriminée et je commence mes premiers tests afin d’affiner ma réflexion
et mieux cibler les potentielles sources de problèmes.

Snoop est un utilitaire gratuit disponible
sur CodePlex
qui permet de parcourir agréablement l’arbre de contrôle de n’importe
quelle application WPF. Il permet, de plus, de modifier les propriétés de ces contrôles
afin de voir l’impact que cela peut avoir sur l’interface… et/ou le comportement de
l’application. Il s’agit d’un de mes outils préférés de debug d’applications WPF.

Et première piste, je me rends compte que si je collapse un des usercontrol présent
dans la fenêtre, le CPU continue d’être à un haut niveau mais baisse de manière assez
notable.

Rendez-vous donc dans le code de ce usercontrol, je me rends compte qu’il y a un backgroundworker
qui est utilisé, que beaucoup d’évènements sont déclenchés, mais pas de trace flagrante
d’un traitement bloquant.

Afin d’analyser plus finement le comportement de ce background worker, et de ces évènements
qui me semblent à première vue potentiellement louches, je me lance donc dans une
session de profiling CPU afin de pouvoir rapidement détecter le point qui pose problème.
J’utilise pour cela le profiler de Visual Studio 2008 Team Suite, et je compare les
résultats avec les résultats proposés par dotTrace.

Après avoir “nettoyé” plusieurs points ennuyeux qui parasitaient ma lecture du rapport
du profiler (essentiellement des appels de ressources I/O, réseau, etc. effectués
en synchrone), je commence à faire une grosse grimace en me rendant compte que le
CPU passe beaucoup de temps non pas à exécuter du code managé (ce qui m’aurait permis
de comprendre simplement où était l’erreur de développement) mais le passe à exécuter
du natif. Bref, ça sent vraiment pas bon, et d’un potentiel problème de développement
je me retrouve sur un problème qui risque d’être beaucoup plus compliqué à résoudre.

Etant dans une application WPF, il y a de bonnes chances que ce temps passé à exécuter
du natif soit du temps passé à exécuter du code lié à l’affichage. Je retourne donc
au sein de Visual Studio afin d’analyser le XAML du usercontrol que j’avais “spotté”
via Snoop et rien ne me choque, je remonte donc l’arbre de contrôle pour essayer de
trouver une piste, et je me rends compte que la fenêtre qui contient le usercontrol
n’a pas de bordure et à l’AllowTransparency d’activé. Ce sont des éléments potentiellement
couteux mais même désactivés le CPU ne souhaite toujours pas prendre de repos.

EasyDropShadowExamplesAlors
qu’une simple suppression du DropShadowEffect qui a été placé à l’intérieur de cette
fenêtre permet de passer d’une consommation de 100% à quelques % ! Et je dois bien
avouer que ce fut pour moi une vraie surprise, tout le monde sait que les
BitmapEffect sont lents et couteux comme je vous l’indiquais il y a presque 3 ans
,
mais de là à prendre 100% du CPU il y a quand même un pas… que WPF a franchi dans
certaines conditions sous TSE !

Conclusion de ce post mortem de séance de tests : Faites donc particulièrement attention
à l’utilisation des BitmapEffects si votre application doit être utilisé via TSE !

image

TextChanged… ou pas (encore)…

C’est dès la première semaine où je suis arrivé chez mon nouvel employeur que j’ai
pu m’exclamer en indiquant que “Rah purée, c’est pas vrai, c’est un bug de WPF…”

Je n’ai pas vu de sourire moqueur de mes collègues mais je suis à peu près sûr que
certains d’entre eux ont dû se dire qu’il était osé de rejeter la faute du bug que
j’avais introduit sur la technologie elle-même et non pas sur une erreur d’inattention.
Et quelques recherches plus tard, je me suis rendu compte… que j’avais bien raison
!

Le scénario est pourtant très simple, il s’agit tout simplement de modifier le texte
d’une TextBox. La particularité de cette modification est que je l’ai réalisé dans
l’évènement TextChanged comme ceci :

image

Je m’attendais à voir le message “Je suis vide” après un click sur mon bouton et bien…
non, ma textbox auparavant remplie devient vide. Et pourtant je rentre bien dans ma
condition et si je mets un espion sur la valeur de la propriété Text elle est bien
définie avec ma chaine. Seul l’affichage n’est pas impacté. Bizarre non ?

Et bien je me suis conforté dans l’idée qu’il s’agissait d’un bug, lorsque je n’ai
pas réussi à reproduire le soucis dans une application .net 4.0. En effet si l’on
fait le test dans VS 2010 et que l’on change de version de framework on se retrouve
avec l’effet désiré ou non !

[Update] Je vous propose ci-dessous le projet de test afin que vous puissiez changer
la version du framework et voir le changement de comportement :

<br />

image

Les nouveautés d’IE 9

Microsoft est en train de perdre du terrain
face à la concurrence représentée par Firefox de la fondation Mozilla, Google Chrome,
et Safari. Autrefois très largement leader, le navigateur est passé sous les 60 ou
50% de parts de marchés selon les sources.
Les challenges de l’éditeur pour la prochaine
version de son navigateur sont simples :

  • La performance
  • Respect des standards
  • Intégration au système d’exploitation et intégration des extensions

Respect des standards

HTML 5 et CSS 3 sont les principaux standards que l’éditeur se doit de parfaitement
respecter pour ne pas être décrié comme ce fut le cas pour d’anciennes versions d’Internet
Explorer.

Alors que la plupart des standards (HTML 5, CSS 3) n’est pas encore finalisé, l’implication
de l’éditeur se fait certes au niveau de leur implémentation au sein d’Internet Explorer
9 mais également au sein des deux principaux organismes responsables de la conception,
validation et finalisation des standards web : le W3C pour l’HTML 5, le CSS et le
SVG, et l’ECMA pour l’ECMA-Script (le nom du standard lié au Javascript).

Pour parvenir à ses fins, l’éditeur fait partie du consortium W3C avec pas moins de
16 membres travaillant activement à la conception et la finalisation du ses standards.
Et le travail est assez important puisque l’on parle d’environ 80 spécifications regroupées
au sein des standards HTML5, CSS 3, SVG et ECMA Script.

Performance

Autre axe stratégique la performance d’Internet Explorer 9 est également un très important
chantier. Avec l’arrivée de frameworks javascript puissants, la montée en puissance
d’Ajax, les applications web se sont fortement complexifiées ces dernières années.
Les performances des navigateurs doit suivre le rythme afin de fournir aux utilisateurs
une expérience optimale.

Et le travail d’engineering effectué par l’éditeur est considérable comme nous allons
le voir au travers du parcours des évolutions apportées avec Internet Explorer 9.

Afin d’améliorer ces performances, l’éditeur a pris comme base Internet Explorer 8
et réalisé des tests de performances sur les sites internet les plus populaires afin
de comprendre le comportement de son navigateur actuel. Ces résultats ont été décomposés
en une dizaine de catégories telles que l’exécution du code javascript, l’affichage
de la page, la gestion de l’HTML du CSS, etc.

image

Figure 1 : Sous-ensembles fonctionnels

Le moteur Javascript

Le premier changement majeur concerne le moteur Javascript d’IE 9. Internet Explorer
8 utilise un interpréteur de code javascript. Comme tous les interpréteurs de code,
celui-ci a l’avantage d’être capable de démarrer l’exécution du code très rapidement,
avec comme contrepartie le fait que l’exécution de ce code ne soit pas très rapide
ce qui va avoir un impact sur les applications utilisant de nombreuses lignes de code
javascript.

La solution adoptée par plusieurs des concurrents d’Internet Explorer a donc été de
passer d’un interpréteur vers un compilateur afin de faire des gains très conséquents
sur le temps d’exécution des applications les plus complexes. Les seuls soucis est
qu’il est donc à présent nécessaire de compiler le code javascript afin d’être capable
de l’exécuter ce qui prend un temps un non négligeable, et ralentit donc le démarrage
de l’exécution des scripts.

Comme on peut le voir le point fort d’une solution étant le point faible de la seconde,
Microsoft a choisi une solution hybride. Internet Explorer 9 utilise à la fois un
interpréteur de code et un compilateur. Le premier est en charge d’exécuter le code
javascript pendant que celui-ci est compilé en arrière-plan. Dès que le résultat de
la compilation est disponible, le navigateur exécutera donc du code natif avec des
performances optimales.

Cette solution est d’autant plus optimale que durant les tests de performances d’Internet
Explorer 8 les ingénieurs de Microsoft se sont rendu compte que même sur des PC multi-cœurs,
le navigateur utilisait quasi-exclusivement un seul de ces cœurs. La moyenne de cœurs
présents sur un PC étant actuellement de 2.46, exécuter du code sur un cœur et compiler
en arrière-plan sur un second cœur ce même code est une solution idéale qui permet
au navigateur de réellement bénéficier des capacités CPU de la machine.

Le parsing du code javascript a également été optimisé. Les ingénieurs de Microsoft
Research ont en effet découvert que sur les principaux sites internet, moins de 50%
du code javascript chargé était effectivement exécuté. L’équipe d’Internet Explorer
a donc modifié le parser de code javascript afin de différer le parsing du code jusqu’�
ce qu’il soit réellement nécessaire.

Autre optimisation, alors qu’Internet Explorer 8 était un hôte générique capable d’appeler
un moteur d’exécution de code VBScript, Javascript ou autre, exposés sous forme de
composants COM, Internet Explorer 9 embarque en son sein le nouveau moteur Javascript.
Il n’est donc plus nécessaire de perdre beaucoup de temps en marshalling pour communiquer
avec le moteur javascript. De plus, pour permettre aux différents moteurs de scripts
de manipuler le DOM de la page affichée, Internet Explorer dupliquait ce DOM vers
tous les moteurs d’exécution de scripts. Le moteur Javascript étant à présent directement
intégré au navigateur, ce dernier manipule le même DOM que le moteur de rendu d’Internet
Explorer.

Le moteur de rendu

Internet Explorer 9 utilise pleinement l’accélération matérielle pour effectuer le
rendu. DirectX, Direct2D et DirectWrite sont au cœur du moteur de rendu. L’idée est
simple, au lieu de passer par le CPU pour effectuer le calcul du rendu, toutes les
opérations de calcul sont effectuées par le GPU. Ce changement est d’autant plus important
que les nouveautés proposées par HTML 5 nécessiteront d’importants calculs.

L’utilisation de l’accélération matérielle est également en cours d’implémentation
sur les navigateurs concurrents mais il est à noter qu’Internet Explorer 9 est le
seul à effectuer le rendu des images, du texte, des vidéos, des images SVG, des Canvas,
et du CSS 3 sur le GPU. La concurrence n’effectue qu’un rendu partiel sur la carte
graphique.

Intégration au système d’exploitation

Après le respect des standards, la performance, la troisième demande la plus fréquente
des développeurs web est de pouvoir mieux intégrer leurs applications web au sein
de l’OS, d’avoir la possibilité d’avoir un comportement qui se rapproche des applications
Windows.

Et la réponse de Microsoft à cette problématique tourne autour de la nouvelle taskbar
introduite avec Windows 7.

L’utilisateur a désormais la possibilité de pinner un site web au sein de la taskbar.
Une fois le site web ainsi attaché, de multiples possibilités sont offertes aux développeurs
web.

Il est à présent possible de s’intégrer à la jumplist afin de faciliter l’accès aux
principales fonctions de l’application web :

image

Figure 2 : Exemple d’intégration à la jumplist

Autre possibilité, l’intégration de boutons intégrés à la miniature de l’application
web. Ces boutons pourront déclencher du code javascript qui permet d’exécuter un certain
comportement en réponse à l’action de l’utilisateur.

image

Figure 3 : Intégration de boutons

Et enfin, pour notifier l’utilisateur il est possible de faire flasher l’icône du
site web ou d’afficher un symbole en overlay :

image

Figure 4 : Exemple d’overlay

<br />