Une accélération matérielle complète pour tous les éléments du Web

IE9 tire désormais mieux que jamais partie des ressources matérielles de votre PC. Pour cela, il s’appuie sur votre GPU qui fut jusqu’à présent complètement inexploité par les navigateurs. Avec Internet Explorer 9, nous sommes ainsi les 1ers à innover dans ce domaine en proposant une accélération matérielle complète de vos pages web.

Pour rappel, nous avions vu quelques premières explications sur les performances des navigateurs dans les 2 articles précédents :

- Performance : essayons de comprendre comment les sites web sollicitent les différentes parties d’un navigateur (ou la genèse de l’architecture d’IE9)
- Performance des navigateurs : regardons ce que les benchmarks classiques mesurent

Les performances globales d’un navigateur vont ainsi bien plus loin que la simple mesure du moteur JavaScript dans lequel nous avons également fortement travaillé avec Chakra. Nos concurrents l’ont d’ailleurs bien compris. En effet, peu de temps après nos 1ères démonstration d’une alpha d’IE9 lors de la PDC 2009, ils ont rapidement annoncé des projets similaires au notre pour booster leurs performances en implémentant également une forme d’accélération matérielle.

Ainsi, la fondation Mozilla a fait le choix avec Firefox 4 beta de reposer sur le même socle technologique que le  nôtre (Direct2D) uniquement disponible sous Windows 7 et Windows Vista. Google de son côté avec Chrome 7 travaille sur le projet ANGLE avec une couche de plus haut niveau s’appuyant sur OpenGL ou DirectX. Ces choix structuraux entrainent bien évidemment des performances différentes. Nous retrouverons d’ailleurs un comparatif entre les navigateurs IE9, Chrome 6/7, Firefox 4 et Opera 10 à la fin de cet article.

Mais avant cela, il est bon de rappeler notre vision de l’accélération matérielle.

Les choix possibles sur l’implémentation de l’accélération matérielle

L’accélération matérielle peut se concrétiser de différentes manières : aucune (comme IE8, Chrome 6, Firefox 3.6.x, Opera 10.x, etc.), partielle (Chrome 7 alpha canary, Firefox 4 beta) ou complète comme IE9.

Dans le cas d’IE9, l’accélération matérielle fait partie des fondements même du navigateur et est ainsi appliqué à tous les étages et à tous les éléments qu’ils soient de type texte, images, arrière plan, contenu SVG, canvas ou audio/video.

Pour mieux comprendre ce processus global, voici un diagramme illustrant les étapes majeures du rendu d’une page dans IE9 :

Rendu du contenu. IE9 accélère cette 1ère étape en faisant appel aux composants Direct2D et DirectWrite de Windows. Comme vous avez déjà peut-être pu le voir, cela permet d’avoir un rendu plus fin (meilleure gestion de l’anti-aliasing) du texte et du contenu vectoriel. Cela permet également de déjà gagner en performance de rendu pour les éléments classiques du HTML comme les images et les textes.

Composition de la page. IE9 fait appel ici à Direct3D. Cela permet alors d’obtenir d’excellentes performances dans certains scénarios gourmant en animation d’éléments (image ou canvas) comme les désormais célèbres démos Flying Images et FishIE Tank. L’accélération de cette étape permet de bénéficier de l’une des caractéristiques les plus intéressantes du GPU pour un navigateur : sa capacité à dessiner des images à très grande vitesse. Par ailleurs, comme la mémoire vidéo dédiée au GPU cache les images, redessiner une page fortement chargée en image devient très rapide.

Composition finale. Une fois que le navigateur a rendu le contenu et composé la page, Windows Vista et Windows 7 utilisent le GPU pour afficher l’ensemble sur l’écran final à travers notre gestionnaire de fenêtres appelé DWM (Desktop Window Manager) en anglais. Comme IE9 utilise DirectX et uniquement DirectX, il y a une meilleure interaction entre IE9 et le DWM ce qui induit une mémoire graphique moins chargée et une meilleure stabilité globale par rapport à d’autres navigateurs qui serait tentés de mélanger plusieurs modules.

Accélération partielle vs Accélération complète

Avec IE9, les développeurs disposent d’un pipeline de rendu entièrement accéléré pour afficher leur markup à l’écran. Rappelons d’ailleurs à ce sujet que cela n’impose pas l’écriture d’un markup spécifique et non standard. Bien au contraire, le développeur conçoit son application comme d’habitude (en utilisant du HTML, du CSS et du JavaScript) et cette dernière tournera simplement potentiellement plus vite sur IE9 que sur un autre navigateur. Bien entendu, cela sera plus ou moins visible en fonction des scénarios et technologies retenus par le développeur. Si ce dernier fait appel massivement à du SVG et des animations CSS3, la différence devrait être marquante. Si c’est juste pour afficher quelques images de manière statique à l’écran, la différence sera simplement minime ou inexistante. Cependant, HTML5 et les technologies associées telles que CSS3 vont permettre aux développeurs de dépasser largement le cadre restrictif imposé par les standards actuels HTML4 et CSS 2.1. Or, pour exécuter ces futures applications particulièrement riches, il faudra que le navigateur tire le maximum des capacités de votre machine.

Nous sommes ainsi les 1er à vous proposer un navigateur armé pour le futur mais nos compétiteurs ne vont naturellement pas nous laisser partir devant tout seul. Cependant, en allant voir les blogs respectifs de Google et Mozilla, on peut découvrir que leur implémentation de l’accélération matérielle travaille sur une des phases mais pas toutes. En effet, fournir une accélération matérielle complète, le tout activé par défaut à l’installation du navigateur, impose des choix d’architecture qui ne sont pas neutres.

Si vous souhaitez par exemple fonctionner sur plusieurs plateformes hétérogènes (Windows, Linux, MacOS), les développeurs doivent introduire des couches d’abstraction qui par nature imposent des compromis. Ces mêmes compromis entrainent ensuite bien souvent des impacts sur les performance empêchant un navigateur de vous fournir des performances dites “natives”, c’est à dire le plus proche possible d’une application utilisant les APIs native du système. En effet, bénéficier au mieux des performances d’un GPU n’est pas une tâche aisée et le fait de passer par des couches et des librairies intermédiaires au lieu d’utiliser les capacités natives de l’OS rend cette tâche encore plus complexe. On ne peut donc que saluer le travail actuellement effectué par les équipes de Google à travers ANGLE mais leur choix devrait malheureusement s’en ressentir au niveau des performances globales.

Pourtant, lorsque vous testez des navigateurs faisant appel en partie à l’accélération matérielle, vous pouvez remarquer que les performances de certains exemples que nous vous avons fournis sur notre site IE Test Drive sont comparable à celles obtenues avec IE9 alors que dans d’autre cas, la différence se fait sentir. Ces différences mettent alors en avant l’impact entre une accélération partielle et complète. Par ailleurs, au fur et à mesure qu’IE supportera davantage de standards Web émergeant, ces implémentations seront de facto accélérée.

L’accélération de la vidéo HTML5 en est un bon exemple. Lors de notre conférence MIX10, nous vous avions montré l’utilisation de l’accélération matérielle pour le décodage vidéo. En Mars, IE9 était donc en mesure d’afficher 2 vidéos HD 720p sur un netbook avec un taux CPU réduit pendant qu’un autre navigateur saturait complètement le CPU tout en perdant des frames sur une seule de ces vidéos. Par ailleurs, comme le pipeline de rendu est entièrement accéléré, vous pouvez même envisager de conserver d’excellentes performances lorsque vous déplacez les vidéos à l’écran, ou si vous vous amusez à y appliquer des styles pour gérer l’opacité par exemple.
 

Mesurer les performances graphiques

Une mesure classique des performances graphiques est le sacro-saint FPS pour Frames Per Second ou le nombre d’images par seconde affichées. Cela mesure donc le nombre de fois qu’un navigateur est en mesure de rafraîchir l’écran par seconde. Cette mesure est bien connue de nos amis les “gamers” (dont je pense faire parti ;-)).

Cependant, faites attention aux démos affichant un FPS supérieur à 60. La raison est toute simple : la quasi totalité aujourd’hui des ordinateurs sont connectés à des écrans plats dont le taux de rafraîchissement est de 60 Hz. Même si l’on voit ainsi apparaître depuis très peu de temps des écrans supportant en entrée du 120 Hz (principalement pour afficher de la 3D en relief), cela représente aujourd’hui une part très faible des ventes d’écran. Le 60 Hz est donc le point de mire des développeurs de jeux vidéo par exemple : avoir une animation à 60 FPS représente l’optimum. Bien entendu, il est possible dans de nombreux cas (en fonction de la complexité du calcul effectué) de rendre et d’afficher une page à plus de 60 images par seconde. Cependant, la plupart des utilisateurs ne le verront pas pour 2 raisons : leur écran sera surement capé à 60 Hz et physiologiquement nous ne sommes pas bien armé pour capter tellement plus ;-). En conclusion, la puissance de calcul demandée au CPU et au GPU pour calculer au dessus des capacités de votre moniteur est purement gâchée. C’est pour cela que les démos de performance graphiques que nous avons mises en place sur le Test Drive se limitent à 60 FPS pour éviter tout simplement de gâcher des cycles de rendu que vous ne verriez de toutes façons pas.

Par ailleurs, pour avoir une réelle idée de la manière dont votre PC est sollicité, il y a bien mieux que se contenter de regarder le nombre final d’images par seconde. En utilisant notre outil d’analyse des performance Windows, les développeurs seront en mesure de découvrir que les autres navigateurs faisant appel à l’accélération matérielle consomment entre 20% et 500% de plus du temps CPU qu’IE9 pendant le rendu d’une image. Ainsi, en fonction de l’opération graphique nécessaire au rendu de la page, l’occupation CPU peut varier d’un navigateur à l’autre. Si cette surconsommation arrive entre 2 mises à jour visuelles (toutes les 16,7 millisecondes donc sur un écran à 60 Hz), la différence ne sera sûrement pas visible à l’œil nu.  Cependant, cela affectera les performances globales de votre machine. Le CPU aura en effet moins de temps à consacrer aux autres tâches tournant sur votre système. Bref, même si 2 navigateurs affichent le même framerate sur une démo/benchmark particulier, la différence sur l’expérience finale d’utilisation de la machine (lire un email, téléchargements en tâche de fond, écouter de la musique, etc.) peut être importante.

Un match au sommet entre IE9, Chrome, Firefox et Opera !

Je me suis amusé à comparer les performances des dernières versions des navigateurs les plus utilisés sur certaines démos spécifiques. Voici les conditions de ces tests.

La machine :

- Sony Vaio Z12 équipé d’un Core i5-540m (double cœurs hyperthreadés), d’une carte nVidia GT330M, de 8 Go de mémoire le tout branché sur secteur (cela peut changer les performances du GPU)
- Windows 7 Ultimate 64 bits
- Lancement uniquement d’un des navigateurs au même moment avec aucune autres applications ouvertes

Les navigateurs :

- Internet Explorer 9 beta qui utilise l’accélération matérielle par défaut
- Opera 10.62 qui n’utilise pas à ma connaissance l’accélération matérielle
- FireFox 4 beta 6 qui utilise l’accélération matérielle par défaut
- Chrome 6 .0.472.63 beta qui n’utilise pas du tout l'accélération matérielle
- Chrome 7.0.530.0 canary build qui n’utilise pas l’accélération matérielle par défaut. Je l’ai donc lancé avec le flag : --enable-accelerated-2d-canvas pour l’activer.

Note : vous observerez que je suis équitable dans la comparaison. Je dirais même que je vais plus loin que ça, je compare une version alpha de Chrome totalement instable à une version beta d’IE très stable (sur ma machine en tout cas). Ce n’est pourtant quasiment jamais le cas lorsque certains comparent IE à d’autres navigateurs. Il est ainsi fréquent que certains s’amusent à comparer IE6 (conçu il y a 10 ans) à un Chrome ou FireFox 3.6 conçu il y a moins d’1 an. Ayez donc l’honnêté intellectuelle de comparer ce qui est comparable que ce soit du point de vue de la sécurité, des performances ou du respect des standards.

Ceci étant dit, allons voir ce que ces navigateurs modernes ont dans le ventre.

Commençons par la démo Fish Tank IE qui fait appel à la balise canvas d’HTML5. Testons avec 1000 poissons affichés simultanément :

Voici le classement du meilleur au moins bon :

 
Internet Explorer 9 beta

Chrome 7 canary avec accélération matérielle activée

Firefox 4 beta 6

Chrome 6 beta

 
Opera 10.62

Internet Explorer 9 beta est donc largement en tête sur cette démo (qui n’est pas un benchmark en tant que tel je vous le rappelle). Chrome 7 effectue un très bon boulot malgré son architecture cross-platform suivi de près par Firefox 4. Les autres navigateurs n’arrivent logiquement pas à tenir la comparaison de part leur architecture non accélérée.

Continuons avec la démo Speed Reading qui fait appel également à la balise canvas et à la balise audio d’HTML5 :

Voici à nouveau le classement du meilleur au moins bon :

Internet Explorer 9 beta

Chrome 7 canary avec accélération matérielle activée

 
Firefox 4 beta 6

Opera 10.62

Chrome 6 beta

Cette fois-ci, la différence se fait encore plus marquante ! IE9 beta effectue l’affichage complet de tous les caractères en 8 secondes là où Chrome 6 beta a besoin de… presque 2h ! Quant à Opera 10.62, il lui a fallu plus d’une 1/2 heure pour aller jusqu’au bout. 

Pour finir sur les démos comparatives sur nos propres jeux de démos, vous pouvez avoir une idée en vidéo des différences en action entres les navigateurs du marché :

Note : cette vidéo utilise le tag vidéo HTML5 (avec le codec H.264) si votre navigateur le supporte. Sinon, il devrait basculer automatiquement sur le player Silverlight.

Alors bien qu’IE9 sort largement au-dessus du lot dans ces démos, vous pourriez leur reprocher de n’être justement que des démos technologiques mises en place par Microsoft. Pour vous convaincre davantage, je vous invite alors à tester la superbe application en production Never Mind the Bullets : http://www.nevermindthebullets.com faisant appel à du SVG, du jQuery, du CSS associés à des énormes images PNG. Sur ma machine, IE9 et Opera affiche l’ensemble de manière parfaitement fluide là ou Firefox 4 et même Chrome 7 rencontrent de grosses difficultés sur la fluidité de l’ensemble.

De manière plus globale, vous trouverez de superbes applications en production référencées sur notre site “Beauty of the Web” : http://www.beautyoftheweb.com lui-même entièrement réalisé en HTML5. A vous de comparer tous ces sites avec différents navigateurs et faites vous votre propre idée des performances d’IE9.

Par ailleurs, un benchmark HTML5 non créé par Microsoft a été récemment mis en place ici : http://webvizbench.com . Je l’ai donc également lancé sur ma machine Vaio et comparé les 5 navigateurs entre eux. Voici le tableau des résultats :

Ce qui donne ce classement du meilleur au moins bon :

Internet Explorer 9 beta

Chrome 7 canary avec accélération matérielle activée

Opera 10.62

Chrome 6 beta

 
Firefox 4 beta 6

On voit ici à nouveau une différence marquante entre IE9 et les autres navigateurs. Le classement est d’ailleurs bien différent des autres. Même si Chrome 7 reste toujours un excellent 2ème, Opéra cette fois-ci remonte dans le classement alors qu’il ne fait pourtant pas usage d’accélération matérielle. L’ensemble de ces classements mets donc en évidence que l’expérience pourra varier en fonction du type de sites web que vous consulterez.

Pour terminer, vous noterez que nos démonstrations d’HTML5 fonctionnent également avec les autres navigateurs car nous ne nous appuyons pas sur certaines spécifications HTML5 ou CSS3 du W3C aujourd’hui encore bien trop instables. Ces spécifications sont parfois implémentées sous forme de brouillon par d’autres en utilisant alors des extensions spécifiques à leur navigateur (comme –moz ou –webkit). Construire une application ou une démo basée sur ces spécifications brouillonnes implique donc souvent de construire cette même application pour un navigateur particulier. Ce n’est pas du tout l’objectif aujourd’hui de la standardisation et des espoirs portés par HTML5 au près des développeurs. C’est certes pratique (voir indispensable) pour commencer à tester à plus large échelle des spécifications émergentes et à les faire évoluer. Mais elles ne devraient pas servir à montrer ce qu’HTML5 est en empêchant les autres navigateurs de les faire fonctionner. Bref, si une soit-disant démo d’HTML5 ne tourne que sur un unique navigateur, ce n’est tout simplement pas une démo d’HTML5 mais une démo d’une forme propriétaire du HTML5.

Conclusion

La concurrence a définitivement du bon ! Reconnaissons ainsi à Firefox d’avoir fait bouger le monde des navigateurs et d’avoir relancé la machine globale il y a quelques années. J’espère que l’on reconnaitra bientôt à IE9 d’avoir fait aussi bouger les lignes en poussant tout le monde à s’intéresser à l’accélération matérielle.  L’accélération matérielle est d’ailleurs une innovation indispensable selon moi pour proposer des applications HTML5 de qualité. En effet, outre la difficulté actuelle de concevoir une application HTML5 (un outillage limité et une énorme partie des spécifications étant non terminée), ces dernières nécessiteront une puissance de calcul sans commune mesure par rapport à ce dont nous avions besoin pour la 4ème génération d’HTML.

Cependant, gardez en tête qu’aujourd’hui toutes les formes d’accélération matérielle ne se valent pas. A ce jour, IE9 est ainsi le premier et l’unique navigateur à fournir une accélération matérielle de tous les contenus HTML5.

David Rousset
Microsoft France