By Juan José Sánchez Penas. Automotive web browsers and web application runtimes have specific needs, compared to platforms such as mobile, STB/TV, desktop and other embedded devices. When building your own web middleware for an automotive platform, many different aspects need to be considered in order to define the right technologies, the architecture to be used, and a good strategy regarding the collaboration with open source projects and communities. In this talk we will discuss those aspects, focusing specifically on WebKit and Chromium, the two main technologies that are being used to build and derive browsers and web runtimes. We will review the alternatives and their status, describe the challenges, explain the functionality and performance, and show demos based on our work at Igalia developing and adapting browsers for automotive, in the context of AGL (Automotive Grade Linux) and GENIVI. (c) Automotive Linux Summit 2018 June 20 - 22, 2018 Tokyo Conference Center Ariake (Japan) https://events.linuxfoundation.org/events/automotive-linux-summit-2018/

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

2. 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

3. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

4. PART 1:
A web browser and runtime for
automotive: motivations and
requirements
Browsers and Web Runtimes for Automotive Juan J. Sánchez

5. Context
Browsers and Web Runtimes for Automotive Juan J. Sánchez

6. 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 define the user experience
Easier to find resources: big number of developers,
training/documentation and tools
Enabled now by new HTML5 features and improved
performance
Browsers and Web Runtimes for Automotive Juan J. Sánchez

7. 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 specific standards (communication, interfaces)
Portability: support of specific hardware boards
Provide both a web browser (internet) and a web runtime
(web apps)
Browsers and Web Runtimes for Automotive Juan J. Sánchez

8. 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 flexibility
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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

9. PART 2:
WebKit and Chromium
Browsers and Web Runtimes for Automotive Juan J. Sánchez

10. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

11. 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, offline &
local storage, connectivity...
Accessibility support
Q&A infrastructure: review process, continuous
integration, testing
Browsers and Web Runtimes for Automotive Juan J. Sánchez

12. 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-specific hooks to
implement generic algorithms
Browsers and Web Runtimes for Automotive Juan J. Sánchez

13. What is a WebKit port?
Browsers and Web Runtimes for Automotive Juan J. Sánchez

14. What is a WebKit port?
Browsers and Web Runtimes for Automotive Juan J. Sánchez

15. 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
Simplification and reduction of the codebase
Users of WebKit need now to make a choice
Browsers and Web Runtimes for Automotive Juan J. Sánchez

16. Differences between WebKit and Blink/Chromium
Blink removes the concept of ’port’ as it was defined 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 flexibility and
no stable API (as provided by WebKit ports)
Dynamics of the open source communities are different
Many architecture changes in Blink/Chromium
Browsers and Web Runtimes for Automotive Juan J. Sánchez

17. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

18. Webkit vs Chromium: pros and cons
WebKit:
Pro: smaller memory footprint
Pro: ports are upstream, easier to integrate core changes
Pro: very flexible 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: difficult to contribute to some core areas (Google)
Browsers and Web Runtimes for Automotive Juan J. Sánchez

19. PART 3:
How to build a web engine for
automotive
Browsers and Web Runtimes for Automotive Juan J. Sánchez

20. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

21. Using WebKitGTK+ or WPE
Pure open source projects, easy to influence 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

22. Derived from Chromium
All the features and flexibility 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

23. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

24. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

25. 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 specific functional requirements and
hardware/software needs
Quite big extra effort required in all the cases
Browsers and Web Runtimes for Automotive Juan J. Sánchez

26. 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)
Browsers and Web Runtimes for Automotive Juan J. Sánchez

27. PART 4:
How to build a web runtime for
automotive
Browsers and Web Runtimes for Automotive Juan J. Sánchez

28. Why a web runtime? (I)
Web apps should be first 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

29. Why a web runtime? (II)
Provide access to car-specific APIs for the web apps
Provide web apps packaging and local
installation/running
Integration with the apps lifecycle (suspend/resume/...)
Security enabled, efficient runtime:
Frequent updates, common well-maintained web engine
Integration with platform security
Browsers and Web Runtimes for Automotive Juan J. Sánchez

30. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

31. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

32. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

33. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

34. 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 specific reference hardware targets
Browsers and Web Runtimes for Automotive Juan J. Sánchez

35. PART 5:
Conclusions and future
Browsers and Web Runtimes for Automotive Juan J. Sánchez

36. 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 finish upstreaming and to
improve performance
Browsers and Web Runtimes for Automotive Juan J. Sánchez

37. 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
Browsers and Web Runtimes for Automotive Juan J. Sánchez

38. Thank you!
Juan J. Sánchez
jjsanchez@igalia.com
@juanjosanchez
Browsers and Web Runtimes for Automotive Juan J. Sánchez