Cobalt

A propos de: Cobalt.

Cobalt est un conteneur d'application léger (c'est-à-dire un runtime d'application, comme une machine virtuelle Java ou Flash Player) qui est compatible avec un sous-ensemble des spécifications HTML5 du W3C. Si vous créez une application Web (SPA) d'une seule page conforme au sous-ensemble Cobalt des normes W3C, elle s'exécutera aussi bien que possible sur tous les appareils pris en charge par Cobalt.

Genèse, Origine, Évolutions, Besoins et Motivation !

Les auteurs Cobalt maintenaient à l'origine un portage de Chromium appelé H5VCC, le conteneur vidéo HTML5 pour consoles, porté sur chacune des principales consoles de jeu, conçu pour exécuter notre application de navigation et de lecture vidéo basée sur HTML5. Cela a pris beaucoup de temps à porter sur chaque plate-forme, composé de 9 millions de lignes de code C ++ (avant de le toucher), était dangereux à modifier sans conséquences imprévues et a été soigneusement conçu pour un environnement multi-processus riche en ressources (par exemple un ordinateur de bureau, un ordinateur portable ou un smartphone moderne).
Après avoir lutté avec cela pendant plusieurs années, nous avons imaginé un environnement qui n'était pas conçu pour le contenu Web de défilement traditionnel, mais qui devait être un environnement d'exécution pour des applications clientes riches construites avec les mêmes technologies - HTML, CSS, JavaScript - et conçues à partir de zéro pour fonctionner sur des appareils électroniques grand public (CE) contraints et intégrés, tels que des consoles de jeu, des décodeurs (par exemple, câble, satellite), des appareils OTT (par exemple, Roku, Apple TV, Chromecast, Fire TV ), Lecteurs de disques Blu-ray et téléviseurs intelligents.
Ces contraintes (qui ne sont pas censées être une liste canonique) rendent ce spectre d'appareils très différent de l'environnement informatique de bureau ciblé par Chromium, FireFox et IE:

• Mémoire limitée. Tous, à l'exception des tout derniers appareils CE coûteux, ont une très petite quantité de mémoire disponible pour les applications. Cela se situe généralement entre 200 et 500 Mo, y compris les graphiques et la mémoire multimédia, par opposition à plusieurs gigaoctets de mémoire CPU (et plus de gigaoctets de mémoire GPU) dans les ordinateurs de bureau et portables modernes et les appareils mobiles.
• CPU lents. La plupart des appareils CE ont des processeurs beaucoup plus lents que ceux disponibles sur un ordinateur de bureau économique. Des problèmes de performance mineurs peuvent être considérablement exagérés, ce qui affecte sérieusement les priorités.
• Moins de cœurs. Les processeurs CE System-on-a-Chip (SoC) n'ont souvent pas autant de cœurs de processeur que nous en avons l'habitude dans les ordinateurs modernes. De nombreux appareils déployés n'ont toujours qu'un seul cœur.
• Parfois, pas de GPU. Tous les appareils CE n'ont pas de GPU monstre pour lancer des shaders pour décharger le travail du processeur. Une stratégie différente est requise pour maximiser l'effet de levier d'un blitter accéléré, ce que possèdent tous les appareils plus anciens. Certains appareils CE plus récents ont un GPU, mais il n'est pas aussi puissant que ce que l'on verrait même sur un ordinateur portable.
• Parfois pas de JIT. De nombreux appareils CE traitent du «contenu de haute valeur» et, en tant que tels, sont très sensibles aux problèmes de sécurité. S'assurer que les pages inscriptibles ne sont pas exécutables est un protocole de sécurité puissant qui peut empêcher un large éventail d'attaques. Mais, comme effet secondaire, cela signifie également aucune capacité à JIT.
• Environnements de développement hétérogènes. C'est lentement le soir, mais tous les appareils CE fonctionnent sur du matériel personnalisé, souvent avec des méthodes propriétaires de construction, d'empaquetage, de déploiement et d'exécution de programmes. Presque tous les appareils CE ont des processeurs ARM ou MIPS au lieu du x86 plus familier. Parfois, la chaîne d'outils ne prend pas en charge les fonctionnalités C ++ 11 contemporaines. Parfois, le système d'exploitation n'est pas POSIX, ou il essaie de l'être, mais il n'est implémenté que partiellement. Parfois, le point d'entrée du programme est dans une autre langue ou architecture qui nécessite un «trampoline» sur du code binaire natif.
• Pas de navigation. Le point d'une application monopage est que vous ne passez pas par la danse de page HTTP chaque fois que vous changez d'écran. C'est lent et fournit une mauvaise rétroaction des utilisateurs, sans parler d'une transition discordante. Au lieu de cela, on charge des données à partir d'un XMLHttpRequest (XHR), puis met à jour son DOM pour refléter les nouvelles données. AJAX! Web 2.0!!
• Pas de défilement. Eh bien, les applications UI SPA de 10 pieds en plein écran peuvent défiler, mais pas comme les pages Web traditionnelles, avec des barres de défilement et une molette de la souris. Le défilement est généralement intégré à l'application très soigneusement, avec la prise en charge d'un pavé directionnel et d'un curseur de mise au point.

Architecture

Les auteurs Cobalt ont créé H5VCC, supprimé la plupart du code Chromium - en particulier WebCore et Chrome Renderer and Compositor - et construit à partir de zéro une implémentation d'un sous-ensemble simplifié de HTML, du modèle CSS Box pour la mise en page et des API Web qui étaient vraiment nécessaires pour construire une application de navigation et de lecture SPA en plein écran.
La pile technologique Cobalt comprend ces composants principaux, à peu près dans une application de haut niveau à un ordre de plate-forme de bas niveau:

• Implémentation Web - C'est là que les normes W3C sont implémentées, produisant finalement une arborescence DOM annotée qui peut être transmise au moteur de disposition pour produire une arborescence de rendu.
• JavaScript Engine - Nous avons, peut - être surprenant, pas écrit notre propre moteur JavaScript à partir de zéro. En raison de la contrainte JITing, nous devons être flexibles avec le ou les moteurs avec lesquels nous travaillons. Nous avons une couche de liaisons qui s'interface avec le moteur JS afin que le script d'application puisse s'interfacer avec des objets nativement soutenus (comme les éléments DOM).
• Moteur de mise en page - Le moteur de mise en page prend un document DOM annoté produit par l'implémentation Web et le moteur JavaScript en travaillant ensemble, et calcule une arborescence de commandes de rendu à envoyer au moteur de rendu (c'est-à-dire une arborescence de rendu). Il met en cache les artefacts de disposition intermédiaires afin que les dispositions incrémentielles suivantes puissent être accélérées.
• Renderer / Skia - Le Renderer parcourt un arbre de rendu produit par le moteur de mise en page, le pixellise à l'aide de la bibliothèque graphique tierce Skia, et l'échange vers le tampon avant. Il y a deux chemins principaux ici, l'un utilisant Hardware Skia sur OpenGL ES 2.0, et l'autre utilisant Software Skia combiné avec le Starboard Blitter à accélération matérielle. Notez que le rendu s'exécute dans un thread différent du moteur de mise en page et peut interpoler des animations qui ne nécessitent pas de nouvelle mise en page. Cela dissocie le rendu de Layout et JavaScript, permettant des animations fluides et cohérentes sur des plates-formes avec une variété de capacités.
• Net / Media - Ce sont les moteurs réseau et média de Chromium. Nous les utilisons directement, car ils ne posent aucun problème particulier avec les contraintes supplémentaires répertoriées ci-dessus.
• Base - Il s'agit de la bibliothèque «Base» de Chromium, qui contient une grande variété de choses utiles utilisées dans Cobalt, Net et Media. Cobalt utilise une combinaison de conteneurs C ++ standard (par exemple, vecteur, chaîne) et Base comme bibliothèque de base pour tout son code.
• Autres bibliothèques tierces - La plupart d'entre elles sont des bibliothèques open source vénérables, en C droit, qui sont généralement incluses dans d'autres logiciels open source. Formater principalement les décodeurs et les analyseurs (par exemple libpng, libxml2, zlib). Nous les dérivons de Chromium, car nous voulons qu'elles soient les versions les plus testées au combat de ces bibliothèques.
• Starboard / Glimp / ANGLE - Starboard est l'interface de portage Cobalt. Une différence majeure entre Cobalt et Chromium est que nous avons créé une couche de portage directe en C droit et porté TOUT le code compilé, y compris Base et toutes les bibliothèques tierces, pour l'utiliser au lieu d'utiliser directement les bibliothèques standard POSIX, qui sont pas cohérent, même sur les systèmes modernes (voir Android, Windows, MacOS X et iOS). De plus, Starboard inclut des API qui n'ont pas été efficacement standardisées sur toutes les plates-formes, telles que la création de fenêtres d'affichage, les événements d'entrée et la lecture de médias. Glimp est un framework d'implémentation OpenGL ES 2.0, construit par l'équipe Cobalt directement sur Starboard, conçu pour adapter les API 3D propriétaires à GLES2. ANGLE Est une bibliothèque tierce qui adapte DirectX à GLES2, similaire à Glimp, mais uniquement pour DirectX.

Le cobalt est comme une pâtisserie feuilletée en couches - peut-être le Baklava. Il ne devrait pas être trop difficile d'extraire l'implémentation et la mise en page Web du haut et d'utiliser simplement le rendu, ou même d'utiliser simplement Base + Starboard + GLES2 comme base d'un nouveau projet.

Le sous-ensemble de cobalt

Oh, nous avons les deux types de balises HTML,
nous avons et

!

Voir la spécification du sous-ensemble Cobalt pour plus de détails sur les balises, les propriétés et les API Web prises en charge dans Cobalt.
Plus à venir.

Emplacements sources intéressants

Tous les emplacements source sont spécifiés par rapport à src/(ce répertoire).

• base/- Bibliothèque de base de Chromium. Contient des utilitaires communs et une abstraction de plate-forme légère, qui a été remplacée dans Cobalt par Starboard.
• net/- Bibliothèque réseau de Chromium. Contient suffisamment d'infrastructure pour prendre en charge les besoins réseau d'un agent utilisateur HTTP (comme Chromium ou Cobalt), un serveur HTTP, un serveur DIAL et plusieurs abstractions pour les primitives de mise en réseau. Contient également les implémentations SPDY et QUIC.
• media/- Médiathèque de Chromium. Contient tout le code qui analyse, traite et gère les tampons de données vidéo et audio. Le décodage multimédia est transmis au matériel de décodage, dans la mesure du possible.
• cobalt/- La maison de tout le code d'application Cobalt. Cela inclut l'implémentation Web, le moteur de mise en page, le moteur de rendu et d'autres fonctionnalités spécifiques à Cobalt.
  • cobalt/build/- Le système de génération de build de base gyp_cobaltet les configurations pour les plateformes prises en charge. (REMARQUE: cela devrait finalement être principalement déplacé vers starboard/.)
• starboard/- Couche de portage de Cobalt. Veuillez consulter Starboard README.mdpour plus d'informations sur le portage de Starboard (et Cobalt) vers une nouvelle plate-forme.
• third_party/- Où vivent toutes les dépendances tierces de Cobalt. Nous ne voulons pas être perjoratifs, nous aimons nos bibliothèques tierces! Cet emplacement est dicté par les règles de gestion des versions de Google OSS ...
  • third_party/starboard/- L'emplacement des ports tiers. Ce répertoire sera analysé automatiquement par gyp_cobalt pour les ports Starboard disponibles.

Création et exécution du code

Voici un guide rapide et sale pour construire le code sous Linux.

1. Tirez depot_toolsdans votre répertoire préféré. Il a été légèrement modifié par rapport à celui de Chrome depot_tools.
   

   git clone https://cobalt.googlesource.com/depot_tools
   

2. Ajoutez ce répertoire à la fin de votre $PATH.
3. Assurez-vous que ces packages sont installés:
   

   sudo apt-get install libgles2-mesa-dev libpulse-dev libavformat-dev \
   libavresample-dev libasound2-dev libxrender-dev libxcomposite-dev
   

4. Assurez-vous que les fichiers d'en-tête C ++ standard sont installés (par exemple libstdc++-4.8-dev).
5. Pour l'instant, nous avons également besoin de rubis:
   

   sudo apt-get installer ruby
   

6. Retirez le bison-3 et installez le bison-2.7. (REMARQUE: nous prévoyons de passer au bison-3 à l'avenir.)
   

   $ sudo apt-get supprimer le bison
   $ sudo apt-get install m4
   $ wget http://ftp.gnu.org/gnu/bison/bison-2.7.1.tar.gz
   $ tar zxf bison-2.7.1.tar.gz
   $ cd bison-2.7.1
   $ sh configure && make && sudo make install
   $ quel bison
   / usr / local / bin / bison
   $ bison --version
   bison (GNU Bison) 2.7.12-4996
   

7. (À partir de ce répertoire) exécutez GYP:
   

   cobalt / build / gyp_cobalt -C debug linux-x64x11
   

8. Si vous obtenez une erreur «clang not found», ajoutez le chemin d'accès au clang de Cobalt à votre $PATHet réexécutez gyp_cobaltcomme ci-dessus. Par exemple:/path/to/cobalt/src/third_party/llvm-build/Release+Asserts/bin
9. Exécutez Ninja:
   

   ninja -C out / linux-x64x11_debug cobalt
   

10. Exécutez Cobalt:
    out / linux-x64x11_debug / cobalt [--url =]
    
    • Si vous souhaitez utiliser à la httpplace de https, vous devez transmettre l' --allow_httpindicateur à la ligne de commande Cobalt.
    • Si vous souhaitez vous connecter à un httpshôte qui n'a pas de certificat validable par notre ensemble d'autorités de certification racine, vous devez passer l' --ignore_certificate_errorsindicateur à la ligne de commande Cobalt.
    • Voir cobalt/browser/switches.ccpour plus d'options de ligne de commande.

Types de build

Cobalt a quatre niveaux d'optimisation de construction, allant du plus lent, le moins optimisé, avec le plus d'informations de débogage en haut (débogage) au plus rapide, le plus optimisé et avec le moins d'informations de débogage en bas (or):

Type	Optimisations	Enregistrement	Asserts	Les informations de débogage	Console
déboguer	Aucun	Plein	Plein	Plein	Activée
développer	Plein	Plein	Plein	Plein	Activée
qa	Plein	Limité	Aucun	Aucun	Activée
or	Plein	Aucun	Aucun	Aucun	désactivé

Lors de la construction pour la sortie, vous devez toujours utiliser une construction en or pour le produit final.

$ cobalt / build / gyp_cobalt -C or linux-x64x11
$ ninja -C out / linux-x64x11_gold cobalt
$ out / linux-x64x11_gold / cobalt

Origine de ce référentiel

Il s'agit d'une fourchette du référentiel de chrome sur http://git.chromium.org/git/chromium.git