Browsers and Web Runtimes for Automotive: Alternatives, Challenges, and Current Status (Automotive Linux Summit 2018)

Browsers and Web Runtimes for Automotive:
alternatives, challenges and current status
Juan J. Sánchez
Automotive Linux Summit, Tokio, June 2018

Myself, Igalia and Web Browsers
Co-founder of Igalia in 2001. 70 engineers. Global
Open Source consultancy: web browsers, multimedia,
graphics, compilers, embedded Linux, networking
Igalia is top contributor to open source web browsers:
WebKit/JSC, Chromimum/V8, Firefox/SpiderMonkey
Working in many industries: automotive, tablets/phones,
smart tv, set-top boxes and other embedded devices
Browsers and Web Runtimes for Automotive Juan J. Sánchez

Outline
1 A web browser and runtime for automotive: motivation
and requirements
2 WebKit and Chromium
3 How to build a web engine for automotive
4 How to build a web runtime for automotive
5 Conclusions and future

PART 1:
A web browser and runtime for
automotive: motivations and
requirements

Context

Motivations
Goal: Web browsing and local/remote web applications
fully available in automotive platforms
Why? Long time trying to use Web technologies in
embedded to replace native totally or partially
Advantages:
Natural combination with open standards and open source
Flexibility and power to deﬁne the user experience
Easier to ﬁnd resources: big number of developers,
training/documentation and tools
Enabled now by new HTML5 features and improved
performance

Requirements
HTML5 interfaces as powerful as native toolkits:
State of the art animations (Performance)
Flexibility to integrate different user experiences
New ways of interacting: accessibility support
Support of speciﬁc standards (communication, interfaces)
Portability: support of speciﬁc hardware boards
Provide both a web browser (internet) and a web runtime
(web apps)

Available technologies and solutions
Option 1) Licensing a proprietary solution: might bring a
reduced time-to-market but involves a cost per unit and
lack of ﬂexibility
Option 2) Deriving browser and runtime from the main
open source browser technologies:
Firefox (Gecko). Mozilla removed support in their engine
for third party browser developers. Servo not fully ready
Chromium
WebKit

PART 2:
WebKit and Chromium

The WebKit project
Web rendering engine (HTML, JavaScript, CSS...)
The engine is the product
Started as a fork of KHTML and KJS in 2001
Open Source since 2005
Among other things, it’s useful for:
Web browsers
Using web technologies for UI development

WebKit features
HTML and XML support
JavaScript support (ECMAScript 5.1)
CSS 2.1, CSS 3 support
SVG support
Support for Plugins (NPAPI, WebKit Plugins)
HTML5 support: multimedia, 3D graphics, advanced CSS
animations and transformations, drag’n’drop, ofﬂine &
local storage, connectivity...
Accessibility support
Q&A infrastructure: review process, continuous
integration, testing

WebKit Architecture
WebKit: thin layer to link against
from the applications
WebCore: rendering, layout,
network access, multimedia,
accessibility support...
JS Engine: the JavaScript engine.
JavaScriptCore by default.
platform: platform-speciﬁc hooks to
implement generic algorithms

What is a WebKit port?

Chromium vs WebKit
Chromium was built on top of its own port of the WebKit
engine until 2013
April 2013: Google announced Blink (fork of WebKit)
Motivations according to Google:
They were not using some parts of WebKit anyway (e.g.
multi-process architecture)
Easier to do ambitious architectural changes
Simpliﬁcation and reduction of the codebase
Users of WebKit need now to make a choice

Differences between WebKit and Blink/Chromium
Blink removes the concept of ’port’ as it was deﬁned in
WebKit (deep platform integration): Skia, V8 and other
libraries cannot be easily replaced
Still possible to use Blink in other platforms, but now
integration happens at Content level. Less ﬂexibility and
no stable API (as provided by WebKit ports)
Dynamics of the open source communities are different
Many architecture changes in Blink/Chromium

Chromium and WebKit today
Both projects have healthy communities and are the basis
of different products
WebKit:
Engine of the Safari web browser and provides the
webview in all the Apple platforms
Upstream ports: WebKitGTK+ (Desktop) and WPE
(embedded) are popular in Linux and embedded
Downstream and proprietary derivatives are also used
Chromium:
Chromium is the open source version of the Google
Chrome browser
QtWebEngine and Chromium Embedded Framework
(CEF) are based on Chromium and popular in Linux and
embedded

Webkit vs Chromium: pros and cons
WebKit:
Pro: smaller memory footprint
Pro: ports are upstream, easier to integrate core changes
Pro: very ﬂexible architecture, easy to plug
components/libraries
Con: less companies contributing (Apple very relevant)
Con: less innovation lately in some areas of the codebase
Chromium:
Pro: more innovation in some areas, Google driving, lots of
developers
Pro: trend of more companies using/testing the technology
Con: no concept of ports, alternatives are not upstream
Con: difﬁcult to contribute to some core areas (Google)

PART 3:
How to build a web engine for
automotive

How to build a web browser for Automotive
Chromium:
Derived from Chromium
On top of QtWebEngine
On top of CEF
WebKit:
On top of WebKitGTK+
On top of WPE

Using WebKitGTK+ or WPE
Pure open source projects, easy to inﬂuence their upstream
development
Reliable and well-known release process and quality
maintenance procedures, strong API and ABI compatibility
Possibility of modifying the whole stack, avoiding a big
delta (e.g. gstreamer vs other media frameworks)
WPE designed to integrate very well with Wayland
Developed by a relatively small team
Reference browsers available, but smaller feature set, less
widely tested in heterogeneous hardware platforms

Derived from Chromium
All the features and ﬂexibility of Chromium at the cost of
increased maintenance complexity
Browsing operations can use Chromium’s Content API.
But browser services like history, bookmarks or incognito
need internal (unstable) APIs
High risk of ending with a big delta compared to upstream
Chromium (which moves very fast)
Changing the UI requires patching the UI code (no toolkit)
Ongoing work to integrate well Chromium with Wayland

Using QtWebEngine
Evolution of the Qt webkit port, but now using Chromium
Library (stable API) for creating apps based on Chromium
Wayland support since Qt 5.10
Some small open source browsers use it but not focused on
being used for browsers, just for embedding small HTML5
parts in Qt applications
Potential issues with LGPLv3 license for some users.
Alternative of paying a license for Qt

Using Chromium Embedded Framework
Another library (stable API) for creating apps based on
Chromium
Browser abstractions are preserved. Multiprocess
architecture preserved and properly interfaced
Browser features from layers above the Content API are
not present in CEF (history, bookmarks or incognito)
Downstream Wayland support based on the work done in
Chromium
Created in 2009. Still mostly a one person project

Web browsers for automotive
Solid alternatives using WebKit or Chromium
Different companies/projects use different solutions. None
seems to be good at everything
Choice depends on speciﬁc functional requirements and
hardware/software needs
Quite big extra effort required in all the cases

A browser for AGL
After a detailed analysis Chromium was selected
Memory restrictions were not critical
The plan is to stay as close to upstream Chromium as
possible
Standards support and full functionality was a priority
Ongoing work on upstream Wayland support for Linux
(Igalia sponsored by Renesas)

PART 4:
How to build a web runtime for
automotive

Why a web runtime? (I)
Web apps should be ﬁrst class citizens: full integration
with native UI
Share resources among web applications:
Hardware resources (e.g. GPU), network cache, etc.
Common strategy for memory pressure scenarios
Shared implementation between web applications:
Same stack for web apps and web browser
Same expected behavior

Why a web runtime? (II)
Provide access to car-speciﬁc APIs for the web apps
Provide web apps packaging and local
installation/running
Integration with the apps lifecycle (suspend/resume/...)
Security enabled, efﬁcient runtime:
Frequent updates, common well-maintained web engine
Integration with platform security

Alternative options to create the runtime
From scratch based on WPE
From scratch based on Chromium
From scratch using one of the solutions that embed
Chromium:
CEF
QtWebEngine
Starting from an existing runtime:
Crosswalk
WebOS’s WAM

Crosswalk
Crosswalk is a web runtime based on Chromium
Available for Android as embeddable webview container
and for Tizen as system-wide application runtime
Adapts the multiprocess model of Chromium to its needs
Created in 2013, never had a big community outside Intel
and Tizen
Number and contributors and contributions getting
smaller since 2015. No commits since July 2017

WebOS’s WAM
WAM is a complete web runtime based on Chromium:
System-wide shared runtime service following
Chromium’s process model
All apps share resources: less memory usage, faster launch
time and task switching
Used in LGE’s WebOS products
It has a mature codebase (developed for about 10 years)
Very recently open sourced. Actively maintained

A web runtime for AGL
Creating a runtime from scratch is a lot of work
The runtime should work on top of the selected web
engine: Chromium for Wayland
WebOS’s WAM seems like a good choice
WebOS’s WAM supports a big part of the requirements
and platform constraints
There is a detailed plan about how to add to WAM what is
missing

Towards WAM in AGL
Some of the most important pending tasks are:
Porting to a new version of Chromium (WAM uses
Chromium 53)
Full integration with AGL’s Application framework
(SMACK, Window Manager, Home Screen, etc.)
Hardware acceleration for multimedia
Multi-seat and multi-screen support
Remove all the pending Qt dependencies
Port to speciﬁc reference hardware targets

PART 5:
Conclusions and future

Conclusions and future: web browsers
WebKit and Chromium are powerful alternatives to build
open source web browsers and bring HTML5 to
automotive Linux
Chromium was selected for AGL, and there is a
downstream, working, integrated version available
Ongoing work by Igalia to ﬁnish upstreaming and to
improve performance

Conclusions and future: web runtime
A web runtime is needed to fully integrate web apps in the
platform
A runtime can be created from scratch on top of Webkit or
Chromium, or an open source available one can be reused
WebOS’s WAM seems to be the best option to start from.
There is a basic prototype working, and more progress is
expected in the coming months

Thank you!
Juan J. Sánchez
jjsanchez@igalia.com
@juanjosanchez

Browsers and Web Runtimes for Automotive: Alternatives, Challenges, and Current Status (Automotive Linux Summit 2018)

More Related Content

What's hot (20)

Similar to Browsers and Web Runtimes for Automotive: Alternatives, Challenges, and Current Status (Automotive Linux Summit 2018) (20)

More from Igalia (20)

Recently uploaded (20)

Browsers and Web Runtimes for Automotive: Alternatives, Challenges, and Current Status (Automotive Linux Summit 2018)