Une nouvelle génération de contenus Web
Je suis Chris Harrelson, responsable de l'ingénierie pour Rendering (transformer le code HTML et CSS en pixels) dans Blink. Depuis plus de huit ans, je suis profondément dans les tranchées des performances de rendu sur le Web, avec pour objectif personnel de faire tout ce que je peux pour rendre une excellente expérience utilisateur sur le Web plus rapide, plus facile et plus fiable. J'ai le plaisir de vous présenter les initiatives que nous avons mises en place durant cette période pour créer une nouvelle architecture de moteur de rendu Chromium de pointe. J'espère que vous aurez bien accueilli ce projet !
En 2021, nous allons achever le processus de conception, de construction et de déploiement de cette architecture. Appelons-la RenderingNG, car il s'agit d'une architecture de rendu nouvelle génération qui offre de bien meilleures performances que ce qui précède. RenderingNG est en cours depuis au moins huit ans et représente le travail collectif de nombreux développeurs Chromium dévoués. Elle ouvre un immense potentiel à la nouvelle génération de contenus Web rapides, fluides, fiables, réactifs et interactifs. C'est également une référence qui, selon moi, définit une nouvelle norme minimale pour tous les moteurs de rendu Web sur laquelle les développeurs peuvent s'appuyer.
Cet article de blog est le premier d'une série. Il explique ce que nous avons créé, pourquoi nous l'avons conçu et comment il fonctionne. Dans ce premier article, je vais commencer par:
- Notre objectif ambitieux.
- La pyramide du succès : principes qui guident notre travail et exemples de ces principes dans la pratique.
- Les fonctionnalités et capacités rendues possibles par RenderingNG.
- Présentation générale des principaux composants de RenderingNG pour les projets.
Étoile polaire
L'objectif principal de RenderingNG est le suivant : l'implémentation du moteur de navigateur et la richesse de ses API de rendu ne doivent pas être un facteur limitant de l'expérience utilisateur sur le Web.
Vous ne devez pas vous soucier des bugs du navigateur qui rendent les fonctionnalités peu fiables ni des problèmes d'affichage de votre site.
Il ne devrait y avoir aucune mystérieuse performance. De plus, vous ne devriez pas avoir à contourner les fonctionnalités intégrées manquantes.
Cela devrait fonctionner.
Je pense que RenderingNG est un grand pas en avant vers cet objectif. Avant RenderingNG, nous pouvions (et faisions) ajouter des fonctionnalités de rendu et améliorer les performances, mais nous avions eu du mal à rendre ces fonctionnalités fiables pour les développeurs et les performances étaient nombreuses. Nous disposons à présent d'une architecture qui résout systématiquement bon nombre de ces problèmes et débloque des fonctionnalités avancées qui n'étaient pas considérées comme réalisables auparavant.
- Il propose des fonctionnalités essentielles à la fois sur différentes plates-formes, appareils et systèmes d'exploitation.
- Il offre des performances prévisibles et fiables.
- Optimise l'utilisation des fonctionnalités matérielles (cœurs, GPU, résolution de l'écran, fréquences d'actualisation, API matricielles de bas niveau).
- N'effectue que le travail nécessaire pour afficher le contenu visible.
- Prise en charge des modèles courants de conception visuelle, d'animation et d'interaction.
- Fournit des API de développement permettant de gérer facilement les coûts de rendu.
- Fournit des points d'extension du pipeline de rendu pour les modules complémentaires du développeur.
- Optimisation de tous les contenus (HTML, CSS, canevas 2D, canevas 3D, images, vidéos et polices).
Comparaison avec d'autres moteurs de rendu de navigateur
Gecko et Webkit ont également mis en œuvre la plupart des fonctionnalités architecturales décrites dans ces articles de blog et, dans certains cas, les ont même ajoutées avant Chromium. ce qui est appréciable ! Bien qu'un navigateur qui devienne plus rapide et plus fiable soit une source de joie et d'impact réel, l'objectif ultime est d'améliorer la base de référence pour tous les navigateurs, afin que les développeurs puissent s'y fier.
La pyramide du succès
Ma philosophie est que la réussite d'une entreprise passe d'abord par la fiabilité, puis par l'évolutivité des performances, et enfin par l'extensibilité.
Comme dans le cas d'une pyramide réelle, chaque niveau fournit une base nécessairement solide pour le niveau supérieur.
Fiabilité
Si nous devons proposer des expériences utilisateur riches et complexes, la première chose dont nous avons besoin est une plate-forme solide. Les principales fonctionnalités et fondements doivent fonctionner correctement et continuer à fonctionner au fil du temps. Il est tout aussi important que ces fonctionnalités soient bien organisées et ne présentent pas de cas particuliers étranges ni de bugs.
Pour cette raison, la fiabilité est la partie la plus importante de RenderingNG. La fiabilité est le résultat de tests satisfaisants, de boucles de rétroaction sur la qualité, de métriques et de modèles de conception logicielle.
Pour vous donner une idée de l'importance de la fiabilité, nous avons passé la majeure partie des huit dernières années à élaborer cette partie. Tout d'abord, nous avons acquis une connaissance approfondie du système, en apprenant à partir de rapports de bugs où se trouvaient les points faibles et en les corrigeant, en lançant des tests complets et en comprenant les besoins en termes de performances des sites et les limites des performances de Chromium. Ensuite, nous avons conçu et déployé minutieusement et progressivement des modèles de conception et structures de données clés. Ce n'est qu'alors que nous étions prêts à ajouter des primitives nouvelle génération pour le responsive design, l'évolutivité et la personnalisation du rendu.
Cela ne signifie pas que rien n'a été amélioré dans Chromium au cours de cette période. En fait, c'est l'inverse qui est vrai ! Ces années ont vu une augmentation constante et soutenue de la fiabilité et des performances, au fur et à mesure que nous avons refactorisé et déployé chaque amélioration étape par étape.
Tests et métriques
Au cours des huit dernières années, nous avons ajouté des dizaines de milliers de tests unitaires, de performances et d'intégration. En outre, nous avons développé des métriques complètes qui évaluent de nombreux aspects du comportement de l'affichage de Chromium lors des tests en local, dans les analyses comparatives des performances, ainsi que dans le monde réel sur des sites réels, auprès d'utilisateurs et d'appareils réels.
Mais quel que soit le degré d'efficacité de RenderingNG (ou d'un moteur de rendu d'un autre navigateur), le développement sur le Web ne sera pas facile s'il existe de nombreux bugs ou des différences de comportement entre les navigateurs. Pour résoudre ce problème, nous maximisons également l'utilisation des tests de plate-forme Web. Chacun de ces tests permet de vérifier un modèle d'utilisation de la plate-forme Web que tous les navigateurs doivent tenter de réussir. Nous surveillons également de près les métriques afin de passer plus de tests au fil du temps et d'améliorer la compatibilité principale.
Les tests de plate-forme Web sont le fruit d'une collaboration. Par exemple, les ingénieurs de Chromium n'ont ajouté qu'environ 10% du nombre total de tests WPT pour les fonctionnalités CSS. Le reste est fourni par d'autres fournisseurs de navigateurs, des contributeurs indépendants et des auteurs de spécifications. Il faut tout un village pour élever le Web interopérable !
Bons modèles de conception logicielle
En outre, fournir des logiciels de qualité de manière fiable est beaucoup plus facile si le code est facile à comprendre et conçu de manière à réduire la probabilité de création de bugs. Nous reviendrons plus en détail sur la conception logicielle de RenderingNG dans les prochains articles de blog.
Performances évolutives
L'obtention d'excellentes performances en termes de vitesse, de mémoire et de consommation d'énergie est le deuxième aspect le plus important de RenderingNG. Nous souhaitons que les interactions avec tous les sites Web soient fluides et réactives, sans pour autant sacrifier la stabilité de l'appareil.
Mais nous ne voulons pas seulement des performances, nous souhaitons des performances évolutives : une architecture qui fonctionne de manière fiable sur les machines d'entrée de gamme et haut de gamme, ainsi que sur toutes les plates-formes de système d'exploitation. C'est ce que l'on appelle le scaling à la hausse, qui consiste à exploiter tout le potentiel de l'appareil matériel, et à le réduire, afin d'optimiser l'efficacité et de réduire la demande sur le système en cas de besoin.
Pour y parvenir, nous devions tirer le meilleur parti de la mise en cache, de l'isolation des performances et de l'accélération matérielle GPU. Examinons chacun de ces éléments l'un après l'autre. Pour être concret, réfléchissons à la manière dont chacun d'eux contribue aux performances d'une interaction extrêmement importante sur les pages Web: le défilement.
Mise en cache
Dans une plate-forme d'interface utilisateur dynamique et interactive telle que le Web, la mise en cache est le moyen le plus important d'améliorer considérablement les performances. Le type de mise en cache le plus connu dans un navigateur est le cache HTTP, mais le rendu comporte également de nombreux caches. Le cache le plus important pour le défilement est celui des textures GPU et des listes d'affichage mises en cache, qui permettent un défilement extrêmement rapide tout en minimisant la décharge de la batterie et en assurant un bon fonctionnement sur divers appareils.
La mise en cache contribue à améliorer l'autonomie de la batterie et la fréquence d'images des animations pour le défilement, mais il est encore plus important qu'elle débloque l'isolation des performances par rapport au thread principal.
Isolation des performances
Sur les ordinateurs de bureau modernes, vous n'avez jamais à craindre que les applications en arrière-plan ralentissent celles sur lesquelles vous travaillez. Cela est dû au multitâche préemptif, qui constitue à son tour une forme d'isolation des performances : s'assure que les tâches indépendantes ne se ralentissent pas les unes les autres.
Sur le Web, le meilleur exemple d'isolation des performances est le défilement. Même sur les sites Web comportant beaucoup de JavaScript lent, le défilement peut être très fluide, car il s'exécute sur un thread différent qui ne dépend pas du thread JavaScript ni du thread de mise en page. Nous avons beaucoup travaillé à RenderingNG pour garantir que tous les défilements possibles sont organisés en threads, grâce à une mise en cache qui va bien au-delà d'une simple liste d'affichage pour des situations plus complexes. Exemples : code représentant des éléments positionnés de façon fixe ou persistante, des écouteurs d'événements passifs et un rendu de texte de haute qualité.
Accélération du GPU
Un GPU permet de générer des pixels et de dessiner à l'écran beaucoup plus rapidement. Dans de nombreux cas, chaque pixel peut être dessiné en parallèle, ce qui augmente considérablement la vitesse. Un composant clé de RenderingNG est le matriciel GPU et permet de dessiner partout. Cette approche utilise le GPU sur toutes les plates-formes et tous les appareils, afin d'accélérer considérablement l'affichage et l'animation du contenu Web. Cela est particulièrement important sur les appareils bas de gamme ou très haut de gamme, qui disposent souvent d'un GPU beaucoup plus performant que d'autres parties de l'appareil.
Évolutivité: outils adaptés à chaque tâche
Une fois que nous disposons de la fiabilité et de l'évolutivité des performances, nous pouvons nous appuyer sur de nombreux outils pour aider les développeurs à étendre les parties intégrées de HTML, CSS et Canvas, sans sacrifier ces performances et cette fiabilité inégalées.
Cela inclut des API intégrées et exposées en JavaScript pour les cas d'utilisation avancés de responsive design, de rendu progressif, de fluidité et de réactivité, et d'affichage avec fils de discussion.
Les API Web ouvertes suivantes, soutenues par Chromium, ont été rendues possibles grâce à RenderingNG et étaient auparavant considérées comme irréalisables.
Tous ont été développés avec des spécifications ouvertes et en collaboration avec des partenaires Web ouverts : ingénieurs dans d'autres navigateurs, experts et développeurs Web. Dans les articles de blog suivants, nous examinerons chacun de ces éléments et expliquerons comment RenderingNG rend possible ces modifications.
- content- visibility : permet aux sites d'éviter facilement l'affichage du contenu hors écran, et le rendu du cache pour les vues d'applications monopages non affichées.
- OffscreenCanvas: permet au rendu du canevas (à la fois de l'API 2D canvas et de WebGL) de s'exécuter sur son propre thread pour d'excellentes performances. Ce projet est également une autre étape majeure pour le Web. Il s'agit de la toute première API Web qui permet à JavaScript (ou WebAssembly) d'afficher une seule page Web à partir de plusieurs threads.
- Requêtes de conteneur: elles permettent de disposer un seul composant de manière réactive, en débloquant tout un univers de composants prêts à l'emploi (actuellement une implémentation expérimentale).
- Isolation de l'origine: permet aux sites d'isoler davantage les performances entre les iFrames.
- Worklets de peinture hors thread principal: permettent aux développeurs d'étendre la manière dont les éléments sont peints, avec du code qui s'exécute sur le thread compositeur.
En plus des API Web explicites, RenderingNG nous a permis de proposer plusieurs "fonctionnalités automatiques" très importantes, qui profitent à tous les sites:
- Isolation de sites : place les iFrames multi-origines dans différents processus de processeur afin de renforcer la sécurité et l'isolation des performances.
- Vulkan, D3D12 et Metal: exploitent des API de niveau inférieur qui utilisent les GPU plus efficacement qu'OpenGL.
- Plus d'animations composées : SVG, couleur d'arrière-plan.
Parmi les autres fonctionnalités à venir débloquées par RenderingNG, nous sommes ravis de vous présenter:
- Animations liées au défilement :
- DOM masqué, mais accessible à la recherche et accessible :
- Transitions d'éléments partagés :
- Mise en page personnalisée :
- Composition hors thread principal ; découper les threads et la composition.
Principaux projets qui composent RenderingNG
Vous trouverez ci-dessous la liste des principaux projets de RenderingNG. Les articles de blog suivants examineront en détail chacun d'eux.
CompositeAfterPaint
Disentangle de la composition du style, de la mise en page et de la peinture. Elle offre ainsi une fiabilité bien améliorée, des performances prévisibles, un débit accru et une utilisation moins importante de la mémoire sans sacrifier les performances. Elle a commencé en 2014 et se terminera cette année.
| Year | Progression |
|---|---|
| 2015 | Listes de présentation des vaisseaux. |
| 2017 | Envoi d'une nouvelle invalidation. |
| 2018 | Arbres de construction (partie 1) |
| 2019 | Expédier les arbres de construction (2e partie) |
| 2021 | Expédition du projet terminée. |
LayoutNG
Réécriture complète de tous les algorithmes de mise en page, pour une fiabilité accrue et des performances plus prévisibles. Il a commencé en 2016 et devrait se terminer cette année.
| Year | Progression |
|---|---|
| 2019 | Flux de blocs expédiés. |
| 2020 | Flexion du vaisseau, retouche. |
| 2021 | Expédiez tout le reste. |
BlinkNG
Nettoyage et refactorisation systématique du moteur de rendu Blink en phases de pipeline clairement séparées. Cela permet une meilleure mise en cache, une plus grande fiabilité et des fonctionnalités de rendu réentrant ou retardé, telles que la visibilité du contenu et les requêtes de conteneur. Il a commencé en 2014 et connu une amélioration progressive, et ce n'est qu'un début. Elle se terminera en 2021.
Accélération GPU partout
Effort à long terme pour déployer la rastérisation, les dessins et les animations GPU sur toutes les plates-formes, tout le temps. L'accélération du GPU permet d'accélérer considérablement la plupart des contenus, car chaque pixel peut être traité en parallèle. C'est également une méthode efficace pour améliorer les performances sur les appareils d'entrée de gamme, qui ont toujours tendance à disposer d'un GPU. Il a débuté en 2014 et s'est terminé en 2020.
| Year | Progression |
|---|---|
| 2014 | Compatibilité avec les canevas Expédié dans du contenu d'activation sur Android. |
| 2016 | Expédier sur Mac. |
| 2017 | Le GPU est utilisé sur plus de 60% des pages vues sur Android. |
| 2018 | Expédiez vos appareils sur Windows, ChromeOS et Android Go. |
| 2019 | Rastérisation GPU par threads. |
| 2020 | Expédiez le contenu Android restant. |
Défilement, animations et décodage organisés en threads
Effort à long terme visant à retirer du thread principal toutes les animations de défilement qui n'entraînent pas de mise en page et le décodage des images. Il a débuté en 2011 et se poursuit aujourd'hui.
| Year | Progression |
|---|---|
| 2011 | Prise en charge initiale du défilement et de l'animation par fils de discussion. |
| 2015 | Écrasement des calques. |
| 2016 | Défilement universel par dépassement de capacité |
| 2017 | L'image est décodée sur le thread du compositeur. |
| 2018 | Animations d'images sur le fil de discussion du compositeur. |
| 2020 | Toujours à position fixe composite. |
| 2021 | Animations de transformation en pourcentage, animations SVG. |
Visualisation
Un processus de dessin et de trame centralisé pour Chromium qui augmente le débit, optimise la mémoire et permet une utilisation optimale des fonctionnalités matérielles. Elle présente également d'autres avantages moins visibles pour les développeurs Web, mais très visibles pour les utilisateurs, tels que le déblocage de l'isolation de sites et la dissociation du pipeline de rendu de l'affichage de l'interface utilisateur du navigateur. Il a débuté en 2016 et se terminera en 2021.
| Year | Progression |
|---|---|
| 2018 | OOP-R disponible sur Android, Mac et Windows. |
| 2019 | OOP-D expédié. OOP-R expédiés partout (sauf Canvas). SkiaRenderer disponible sous Linux. |
| 2020 | SkiaRenderer disponible sur Windows et Android Mise à disposition de Vulkan sur Android. |
| 2021 | SkiaRenderer disponible sur Mac (et bientôt sur ChromeOS) |
Définitions des termes dans le tableau ci-dessus:
- Sortie numérique
- Composeur d'affichage hors processus. La composition d'écran correspond au même type d'activité qu'un compositeur d'OS. "Hors processus" signifie que l'opération est effectuée dans le processus de visualisation, et non dans le processus d'affichage de la page Web ou dans le processus d'UI du navigateur.
- PPE
- Trame hors processus. La trame convertit les listes d'affichage en pixels. "Hors processus" signifie l'effectuer dans le processus de visualisation plutôt que dans le processus d'affichage de la page Web.
- SkiaRenderer
- Nouvelle implémentation du compositeur d'affichage pouvant prendre en charge l'exécution sur différentes API GPU sous-jacentes, telles que Vulkan, D3D12 ou Metal.
Rendu accéléré des canevas avec fils de discussion et accélération
Il s'agit du projet qui a permis de mettre en œuvre les éléments architecturaux qui ont permis le lancement d'OffscreenCanvas. Il a commencé en 2015 et se terminera en 2021.
| Year | Progression |
|---|---|
| 2018 | Expédition hors écranCanvas. |
| 2019 | Expédier ImageBitmapRenderingContext. |
| 2021 | Expédiez le message OOP-R. |
VideoNG
Nous œuvrons sur le long terme pour permettre une lecture efficace, fiable et de haute qualité des vidéos sur le Web.
| Year | Progression |
|---|---|
| 2014 | Introduction d'un framework de rendu basé sur Mojo. |
| 2015 | Lancement de Project Butter et des superpositions vidéo pour un rendu vidéo plus fluide |
| 2016 | Déploiement de pipelines de décodage et de rendu unifiés pour Android et les ordinateurs de bureau. |
| 2017 | HDR et rendu vidéo avec correction des couleurs livrés. |
| 2018 | Pipeline de décodage vidéo basé sur Mojo envoyé. |
| 2019 | Pipeline de rendu vidéo basé sur la surface expédié. |
| 2021 | Le rendu du contenu protégé 4K est désormais pris en charge sur ChromeOS. |
Définitions des termes dans le tableau ci-dessus:
- Mojo
- Un sous-système d'IPC nouvelle génération pour Chromium
- Surface
- Concept intégré à la conception du projet Visualisation
Conclusion
Je suis ravi de l'amélioration de l'affichage sur le Web et dans Chromium. Je pense que le rythme continuera de s'accélérer dans les années à venir, car nous pourrons nous appuyer sur la base solide de RenderingNG.
Restez à l'écoute pour de nombreux autres posts à venir qui détailleront davantage cette nouvelle architecture, comment elle a vu le jour et comment elle fonctionne.
Photo des appareils par Eirik Solheim sur Unsplash
Illustrations : Una Kravets.