Navigateurs web modernes : tous vers l’accélération matérielle

Cet article est extrait du blog officiel d’Internet Explorer France pour les Professionnels de l’informatique.

HTML5 et ses amis permettront dans le futur l’écriture d’une nouvelle génération d’applications très riches visuellement. Il faudra alors faire très attention à l’accessibilité de ces nouvelles applications. Mais il faudra aussi que les navigateurs modernes soient capables de rendre la complexité de ces nouvelles applications avec la plus grande fluidité possible. Pour cela, il faut être capable d’exploiter au mieux les ressources de la machine, que ce soit un PC ou un périphérique portable comme un téléphone ou une tablette.

C’est avec cet objectif en tête qu’IE9 a été conçu depuis le début. Il est donc capable d’exploiter la puissance de traitement du GPU présent sur une machine tournant sous Windows Vista ou Windows 7 (et bientôt également du GPU présent dans tous les téléphones Windows Phone 7). Mettre en place ce que l’on appelle donc “l’accélération matérielle” semble donc indispensable si l’on souhaite pouvoir exploiter au mieux les merveilleuses promesses d’HTML5. D’ailleurs l’ensemble de l’industrie semble d’accord sur ce point : IE9 propose une accélération matérielle activée par défaut, Firefox 4.0 aura également une accélération matérielle par défaut, Google planche dessus pour Chrome (mais se refuse pour l’instant à l’activer par défaut) et plus récemment Opera (avec la beta 11.50) a annoncé des plans similaires. Certains tentent de vous faire croire que tout ce qui compte, c’est d’avoir une forme d’accélération matérielle dans son navigateur. Cependant, la mise en œuvre technique de l’accélération matérielle n’est pas chose aisée. Ainsi, l’accélération matérielle proposée par les différents acteurs des navigateurs ne se valent pas. C’est ce que nous allons avoir ensemble ici.

Il y a 2 raisons à cette différences de performances. La 1ère est simplement liée au fait que ce n’est pas simple à implémenter. Le talent de chacune des équipes de développement va donc jouer un rôle crucial ici tant en terme de performance que de stabilité. La 2ème est lié au choix effectué par certains éditeurs. Certains (comme nous) préfèrent se limiter à quelques plateformes (Windows Vista et Windows 7) pour optimiser au mieux les performances de notre navigateur. D’autres (comme Opera, Google et Mozilla) ont historiquement fait le choix d’être multiplateformes. C’est tout à leur honneur mais cela augmente naturellement la complexité de mise en place de l’accélération matérielle de par l’architecture nécessaire à déployer. Cependant, il semblerait que ces derniers, même s’ils ont fait des annonces d’accélération matérielle multiplateformes, privilégient pour le moment les mêmes plateformes que nous (Vista & Win7). Les utilisateurs de MacOS et de distributions Linux semblent pour l’instant lésé de ce côté.

Sommaire :

1 – Protocole, machine et navigateurs utilisés pour les tests
      - Comment vérifier si l’accélération matérielle est bien activée ?
      - Méthodologie pour analyser l’occupation GPU
2 – Benchmarks sur Microsoft IE Test Drive
      - Speed Reading avec GPU nVidia
      - Speed Reading avec GPU Intel
      - HTML5 Blizzard avec GPU nVidia
      - HTML5 Blizzard avec GPU Intel
3 – Benchmarks extérieurs à Microsoft
      - Jeu HTML5 VII avec GPU nVidia
      - Jeu HTML5 VII avec GPU Intel
      - Hardware Acceleration Stress Test par Mozilla
      - The Man in Blue Animation Benchmarking
      - Asteroids HTML5 Canvas 2D Rendering and JavaScript Benchmark
4 – Conclusion

Note : cet article fait suite à celui-ci : Une accélération matérielle complète pour tous les éléments du Web où je vous parlais déjà de certains de ces points. Comme tout le monde a progressé entre temps, je me suis dit que c’était une bonne occasion de mettre à jour ce comparatif tout en creusant un peu plus certaines parties comme l’occupation GPU.

1. Protocole, machine et navigateurs utilisés pour les tests

L’ensemble des tests ont été réalisés sous Windows 7 SP1 Ultimate 64 bits. La machine utilisée est un Sony Vaio Z (référence exacte VPCZ12C5E) dont je vous ai déjà parlé ici : Sony Vaio Z ou la quête de la machine portable parfaite . Cette machine est équipée d’un Core i5 540m (double cœurs hyperthreadés soit 4 processeurs logiques vu sous Windows), de 2 GPUs (nVidia GT330m et le GPU Intel HD Graphics intégré) et de 8 Go de mémoire vive.

Par ailleurs, suite au passage à la beta 12 de Firefox 4.0, j’ai perdu l’accélération matérielle car mes drivers ont manifestement été blacklistés entre la beta 11 et la beta 12. Comme Opera 11.50 beta ne voulait pas non plus de mes drivers (qui marchaient pourtant très avec la RC d’IE9…), j’ai décidé de les mettre à jour.

Voici donc la version des drivers nVidia : 263.00 (8.17.12.6300) et Intel : 2022 (8.15.10.2202) que j’ai utilisés. Je vais en effet utiliser les 2 GPUs dans ces tests pour que l’on puisse constater du bénéfice obtenu en fonction de la puissance sous-jacente.

Note : si vous avez aussi un Vaio Z et que vous souhaitez mettre à jour vos pilotes graphiques, il faut suivre cette procédure un peu ésotérique : Our discoveries on Vaio Z’s Hybrid Graphics . Espérons qu’à l’avenir, certains éditeurs soient moins rigides sur les mises à jour de drivers pour nous laisser bénéficier de leur accélération matérielle.

Voici les versions des navigateurs retenus pour ce test :

- Microsoft Internet Explorer 9 RC (9.0.8080.16413)
- Mozilla Firefox 4.0 beta 12
- Google Chrome 11.0.686.1 dev
- Opera 11.50 labs

Safari n’utilisant pas à ma connaissance d’accélération matérielle, je ne l’ai tout simplement pas retenu pour ce test. Nous noterez aussi au passage qu’IE9 est la version la plus stable du lot et la plus proche d’une version finale. J’ai eu par exemple quelques freezes et crashes d’Opera 11.50 et également quelques soucis avec Firefox 4.0 beta 12 qui refusait parfois de se fermer.

Comment vérifier si l’accélération matérielle est bien activée ?

Si vous souhaitez également de votre côté comparer la performance des différents navigateurs sur votre machine, pensez bien avant à vérifier si l’accélération matérielle est bien activée.

Sous IE9, c’est activé par défaut si votre GPU et vos pilotes graphiques le permettent. Nous gérons par exemple une liste noire de pilotes graphiques instables qui entrainent de facto la désactivation de l’accélération matérielle. Pour le vérifier, rendez-vous dans les “Options Internet” puis “Avancé” et vérifiez bien que la case “Utiliser le rendu logiciel au lieu du rendu GPU*” n’est pas cochée. Sinon, c’est uniquement votre CPU qui sera sollicité pour le rendu et vous aurez donc des performances nettement inférieures.

Sous Firefox 4.0, il faut taper dans la barre d’adresse “about:support” et dans la section “Accélération graphique” vérifier si Direct2D et DirectWrite sont bien activés. Par exemple, sur ma machine, voici le résultat avant et après la mise à jour de mes pilotes:

Sous Chrome, il faut l’activer manuellement en tapant dans la barre d’adresse “about:flags” et cliquer sur “Activer” dans la section “2D canvas et accélération matérielle".

Sour Opera, il faut se rendre dans l’aide et “About Opera” et vérifier que “Vega backend” est bien sur “OpenGL” et pas “Software”.

Note : j’espère que vous noterez que je fais des efforts pour tenter de comparer de manière la plus loyale possible les différents navigateurs. J’aurais pu me contenter de tester les navigateurs en l’état, sans activer l’accélération matérielle et sans mettre à jour mes pilotes vu qu’IE9 RC fonctionnait très bien tel quel. Mais avec Stanislas, nous avons à cœur de comparer ce qui est comparable. Je ne vois ainsi pas l’intérêt aujourd’hui de comparer un IE8 à un Chrome 9 ou un Opera 11. C’est donc avec cette démarche en tête que j’ai retenu les toutes dernières versions des navigateurs concurrents.

Méthodologie pour analyser l’occupation GPU

Pour finir sur le protocole retenu, sachez qu’à chaque fois, je n’ai laissé qu’un seul navigateur ouvert et aucune autre application ouverte en parallèle (à part les outils de mesure). Par ailleurs, j’ai utilisé l’utilitaire GPU-Z me permettant d’analyser en temps réel le taux d’occupation du GPU.

Pour aller encore plus loin sur l’analyse de l’utilisation GPU, j’ai utilisé la technique en partie décrite ici : Measuring Browser Performance with the Windows Performance Tools en utilisant les outils du SDK Windows notamment GPUView. On peut ainsi voir en détail la charge du GPU ainsi que le FPS (Frame Per Second) dans le temps associé à un processus particulier. Ce sont des outils en général utilisés pour débugger les problèmes de performances dans les applications 3D (DirectX ou XNA). Mais ils sont ici particulièrement intéressants pour mettre en lumière les différences de performance entre les navigateurs.

Allez, trêve de bavardage, regardons ce qu’ils sont dans le ventre ces derniers petits navigateurs accélérés !

Lire la suite sur le Blog

David Rousset Evangéliste Web Microsoft France

David Cohen