PDC09 : aperçu des nouveautés d’Internet Explorer 9 pour les développeurs

PDC09 : aperçu des nouveautés d’Internet Explorer 9 pour les développeurs

  • Comments 13
IE9_001

Une surprise nous a été réservée à la PDC 2009 (Professional Developer Conference) qui se déroule actuellement à Los Angeles. Nous avons pu voir un premier état du développement d’Internet Explorer 9.

IE9_001

Ainsi, non seulement nous avons amélioré les performances générales tout en supportant toujours mieux les standards (c’est la moindre des choses me direz-vous) mais nous avons également montré de quelle manière IE et Windows pouvaient tirer parti de la puissance disponible du matériel fourni dans un PC. Plus spécifiquement du GPU de la carte graphique. Le GPU ? Et oui, cette petite puce surpuissante qui vit dans votre PC souvent sous-utilisée. L’idée est de s’en servir pour faire un rendu accéléré de l’ensemble des graphiques et du texte présents dans les pages web : une nouveauté qui est totalement inédite ! Ainsi les développeurs web vont pouvoir découvrir des gains de performance importants (accompagnés d’autres bénéfices) sans avoir heureusement à ré-écrire leurs sites. IE revient donc en force !

Amélioration des performances du moteur Javascript. Les performances d’un navigateur dépendent de plusieurs sous-systèmes. Par conséquence, les sites existants sollicitent de manière très variée le navigateur.

Par exemple, 2 sites web peuvent parfois se ressembler fortement mais avoir des implémentations sous-jacentes engendrant des performances très différentes. Cela dépend bien entendu de la manière dont les développeurs web conçoivent le site en question. L’un d’entre eux peut passer la plupart de son temps au sein du moteur Javascript et à jouer avec le DOM tant dis que l’autre peut passer le clair de son temps sur le rendu et la mise en page. Ainsi un site conçu sous la forme d’une application RIA moderne (comme les applications type Web-mail, ou Office Web Apps) peut stresser les couches du navigateur de manière totalement différentes en fonction des actions effectuées par l’utilisateur. Les applications RIA sont donc d’excellentes candidates à la mise à l’épreuve d’un navigateur.

L’équipe en charge d’IE 9 est justement entrain de plancher sur le comportement de la prochaine version en analysant le temps passé sur chacune des couches en testant des types de sites divers et variés. Dans le diagramme ci-dessous, on voit ainsi que l’un d’entre eux engendre une consommation principale au niveau du moteur d’exécution Javascript et du marshalling, pendant qu’un autre passe son temps dans les scripts et le rendu. En comparaison, Excel Web App n’utilise quasiment pas de temps lié au scripting mais plus de la moitié sur le rendu et la mise à en page.

IE9_003

On voit donc ici qu’il ne faut pas uniquement se concentrer sur le moteur d’exécution Javascript si l’on souhaite augmenter les performances globales de la navigation offerte à l’utilisateur. Il n’en constitue finalement que l’une des briques.

Malgré tout, nous ne négligeons pas ce moteur pour autant. IE 8 avait déjà fait des progrès notables et nous continuons sur la bonne voie. Pour pouvoir évaluer ce moteur, il faut le soumettre à des “benchmarks”. Ces derniers ont malheureusement parfois peu d’intérêts car ils sont peu représentatifs de l’expérience vécue par le naviguant devant sa machine. Toujours est-il que l’un des tests les plus connus provient de l’équipe Webkit d’Apple sous le nom de SunSpider. Alors, jouons le jeu de manière honnête avec notre version alpha d’IE 9 :

IE9_004

On voit donc ici IE7 comparé aux versions finales des navigateurs les plus représentatifs du marché actuellement. Nous avons également ajouté les mêmes navigateurs en cours de développement pour les comparer à IE9 Alpha. On voit donc désormais que les différences à ce niveau vont devenir anecdotiques et que le combat sur les performances et l’expérience utilisateur va maintenant devoir s’effectuer sur d’autres parties.

En effet, même si notre souhait est clairement d’optimiser au maximum le moteur Javascript d’IE (pour qui sait, un jour devenir enfin leader sur ce domaine), nous sommes attachés à améliorer les performances de l’ensemble des briques du navigateur. Notre but est simple : offrir les meilleures performances sur l’ensemble des sites Web en production sur la toile et pas uniquement sur des benchmarks visant telle ou telle fonction Javascript. Pour cela, une idée innovante fait son apparition pour booster les autres couches.

Bénéficier de la puissance des GPUs grâce à DirectX et Windows. L’idée est simple : nous avons en réserve une puissance de calcul offerte par le GPU accessible via la couche DirectX. Les développeurs d’Internet Explorer 9 ont donc basculé de l’ancien jeu d’APIs graphiques Windows (nommé GDI) vers une famille de DirectX. Les points d’entrée sont Direct2D et DirectWrite qui vont permettre de rendre par le GPU l’ensemble des zones graphiques et textuelles afin de soulager le CPU. C’est ce que l’on appelle passer d’un rendu “software” vers “hardware” ou en français d’un rendu logiciel vers un rendu accéléré. On peut se rendre compte du bénéfice des performances apportées par cette technique à travers cet interview par exemple.

Les développeurs web vont donc pouvoir bénéficier d’un large écosystème de GPUs sur le marché qui vont booster les performances de rendu de leurs sites tout en continuant à les réaliser en suivant les bonnes pratiques d’utilisation des standards comme ils l’ont toujours fait. Cela est totalement transparent sur le HTML fourni au navigateur.

D’autre part, non content d’apporter un surcroit de performance, cette nouvelle technologie de rendu permet une nette amélioration de la qualité et la lisibilité du texte comme on peut le voir sur cette copie d’écran issue du keynote de la PDC:

IE9_005

Continuer à progresser sur les standards. Si les développeurs souhaitent de plus en plus de fonctionnalités au sein du navigateur afin de fournir de meilleures applications à leurs utilisateurs, ils ne veulent pas en contre partie ré-écrire et tester en boucle leur code sur l’ensemble des navigateurs. La manière la plus simple d’éviter cela est de se mettre d’accord sur les standards à respecter.

Les tests ACID sont une chose importante à passer mais ils ne constituent qu’un sous-ensemble de la norme à respecter. Ainsi, non seulement IE 8 passe avec succès le test ACID 2 mais il implémente également un haut niveau de support de la norme CSS 2.1. Pour cela, les équipes de développement lui ont fait passer 7200 tests du W3C. Or, certains standards ne proposent pas de tests de validation et deviennent donc ainsi plus difficiles à implémenter car sujets potentiellement à différentes interprétations. Par conséquence, il est plus difficile pour le développeur d’avoir la garantie du bon support de certaines fonctionnalités. Bref, il faut garder en tête que les tests ACID ne nous apportent pas la garantie d’un support effectif de l’ensemble de la norme qu’ils sont censés éprouver. Loin de là.

Toujours est-il qu’un test comme ACID 3 est largement utilisé pour communiquer autour du support de CSS 3. Acid3 teste ainsi environ 100 aspects de différentes technologies dont certaines sont toujours à l’état de “working draft” (en cours d’élaboration). De la même manière que nous avons joué le jeu avec le benchmark d’Apple, regardons l’état actuel d’IE 9:

IE9_002

Il reste donc du chemin à parcourir. Mais au fur et à mesure que nous améliorons le support des technologies que les développeurs utilisent, le score devrait logiquement augmenter de facto.

Selon nous, un exemple plus parlant du support des standards (du point de vue du développeur web) tourne autour des coins arrondis (ou rounded corners). Voici un exemple de rendu IE9 accompagné du markup associé :

IE9_006

Un autre exemple qui nous parait important est le sélecteur CSS3. Voici une page de tests qu’une partie de la communauté du développement web a assemblé : css3.info. Vous trouverez ci-dessous une bonne illustration des progrès effectués par IE9 sur IE8 dans un scénario plus réel.

IE9_007

Ce genre de tests communautaires peuvent donc être très utiles. Ainsi, les équipes IE souhaitent travailler de concert avec la communauté, le W3C et d’autres membres du groupe de travail pour définir ensemble des suites de tests de validations réels autour de CSS 3/HTML 5 comme ceux sur lesquels ils ont travaillé autour de CSS 2.1 pour IE8. Par exemple, ce lien teste l’une des APIs de stockage d’HTML 5. Il se trouve que certains navigateurs (comme IE8) la supporte aujourd’hui correctement alors que d’autres pas encore.

Ce travail de fond, à la fois sur le produit en lui-même et sur les suites de tests, a pour but de fournir au final une plateforme interopérable sur laquelle les développeurs pourront s’appuyer sereinement pour développer leurs applications. 

Pour conclure et pour aller plus loin, voici quelques vidéos intéressantes à regarder :

- Introduction, and Interoperable Standards

- Early look at the Script Engine

- Hardware accelerated graphics and text in the browser via Direct2D

David

Page 1 of 1 (13 items)
Leave a Comment
  • Please add 8 and 8 and type the answer here:
  • Post