Import Cobalt 23.master.0.307905
3229 files changed
tree: 0f66c32e99b2bdf58fb87d0acbfb332a4883e074
  1. base/
  2. build/
  3. build_overrides/
  4. buildtools/
  5. cobalt/
  6. components/
  7. content/
  8. crypto/
  9. docker/
  10. glimp/
  11. nb/
  12. net/
  13. precommit_hooks/
  14. starboard/
  15. testing/
  16. third_party/
  17. tools/
  18. url/
  19. .clang-format
  20. .codespellignorelines
  21. .gitignore
  22. .gn
  23. .pre-commit-config.yaml
  24. .pylintrc
  25. .style.yapf
  26. AUTHORS
  27. BUILD.gn
  28. CONTRIBUTING.md
  29. docker-compose.yml
  30. download_resources.py
  31. LICENSE
  32. README.md
  33. requirements.txt
  34. setup.cfg
  35. starboard_configuration.py
README.md

Cobalt

Overview

Cobalt is a lightweight application container (i.e. an application runtime, like a JVM or the Flash Player) that is compatible with a subset of the W3C HTML5 specifications. If you author a single-page web application (SPA) that complies with the Cobalt Subset of W3C standards, it will run as well as possible on all the devices that Cobalt supports.

Motivation

The Cobalt Authors originally maintained a port of Chromium called H5VCC, the HTML5 Video Container for Consoles, ported to each of the major game consoles, designed to run our HTML5-based video browse and play application. This took a long time to port to each platform, consisted of 9 million lines of C++ code (before we touched it), was dangerous to modify without unintended consequences, and was thoroughly designed for a resource-rich, multi-process environment (e.g. a desktop, laptop, or modern smartphone).

After wrestling with this for several years, we imagined an environment that was not designed for traditional scrolling web content, but was intended to be a runtime environment for rich client applications built with the same technologies -- HTML, CSS, JavaScript -- and designed from the ground-up to run on constrained, embedded, Living Room Consumer Electronics (CE) devices, such as Game Consoles, Set-Top Boxes (e.g. Cable, Satellite), OTT devices (e.g. Roku, Apple TV, Chromecast, Fire TV), Blu-ray Disc Players, and Smart TVs.

These constraints (not intended to be a canonical list) make this device spectrum vastly different from the desktop computer environment targeted by Chromium, FireFox, and IE:

  • Limited Memory. All except the very latest, expensive CE devices have a very small amount of memory available for applications. This usually is somewhere in the ballpark of 200MB-500MB, including graphics and media memory, as opposed to multiple gigabytes of CPU memory (and more gigabytes of GPU memory) in modern desktop and laptop computers, and mobile devices.
  • Slow CPUs. Most CE devices have much slower CPUs than what is available on even a budget desktop computer. Minor performance concerns can be greatly exaggerated, which seriously affects priorities.
  • Fewer cores. CE System-on-a-Chip (SoC) processors often do not have as many processor cores as we are used to in modern computers.
  • Minimal GPU. Not all CE devices have a monster GPU to throw shaders at to offload CPU work. As CE devices now have a standard GPU (though not nearly as powerful as even a laptop), OpenGL ES 2.0 is now required by Cobalt.
  • Sometimes No JIT. Many CE devices are dealing with “High-Value Content,” and, as such, are very sensitive to security concerns. Ensuring that writable pages are not executable is a strong security protocol that can prevent a wide spectrum of attacks. But, as a side effect, this also means no ability to JIT.
  • Heterogeneous Development Environments. This is slowly evening out, but all CE devices run on custom hardware, often with proprietary methods of building, packaging, deploying, and running programs. Almost all CE devices have ARM processors instead of the more familiar x86. Sometimes the toolchain doesn‘t support contemporary C++11/14 features. Sometimes the OS isn’t POSIX, or it tries to be, but it is only partially implemented. Sometimes the program entry point is in another language or architecture that requires a “trampoline” over to native binary code.
  • No navigation. The point of a Single-Page Application is that you don‘t go through the HTTP page dance every time you switch screens. It’s slow, and provides poor user feedback, not to mention a jarring transition. Instead, one loads data from an XMLHttpRequest (XHR), and then updates one's DOM to reflect the new data. AJAX! Web 2.0!!
  • No scrolling. Well, full-screen, 10-foot UI SPA apps might scroll, but not like traditional web pages, with scroll bars and a mouse wheel. Scrolling is generally built into the app very carefully, with support for a Directional Pad and a focus cursor.

Architecture

The Cobalt Authors forked H5V