Day 1

Lightning talks!!

​

haraken@

2019 Apr

(๑>ᴗ<๑)

*

*

*

*

​

Rule

• I asked all speakers to insert one talking point that will get a storm of applause

​

• When you find that point, please give a big round of applause :D

​

Let's practice!

​

​

​

It's important to improve

documentation of the code base

50% increase!!

​

SGTM

(๑˃̵ᴗ˂̵)و

Media Capture�for the Web

​

BlinkOn 10, April 8, 2019

​

Rijubrata Bhaumik @riju

​

{ Generic Sensors, Web NFC, MediaCapture .. }

Web Media Capture

11

​

​

​

Capturing images used to be painful

Then we shipped Image Capture API in M59

Problem solved?

​

But … we heard you need a more capable API!

12

12

navigator.mediaDevices

.getUserMedia({video: true}) …

​

videoTrack.applyConstraints({

advanced: [{

focusMode: "manual",

focusDistance: 5

}]

});

​

For those compelling real-world u$e ca$e$

13

13

Focus Stacking

Remove defocused objects & background

Depth estimation in Augmented Reality

… and more

Then we saw the light

14

navigator.mediaDevices

.getUserMedia({video: true}) …

​

videoTrack.applyConstraints({

advanced: [{

exposureMode: "manual",

exposureTime: 50

}]

});

​

15

15

Well, there’s also that High Dynamic Range thing...

-4 stops

​

-2 stops

​

+2 stops

​

+4 stops

​

Tone-mapped HDR image

Also, we heard y’all like video conferencing too?!

16

Media capture in depth? We have you covered!

17

Demos in depth

18

18

(Thank You!)

mcasas, reillyg, guidou, chfremer, astojilj, slightlyoff, anssiko .. and many many more

19

Oilpan: Concurrent Marking

BlinkOn 10, Toronto, Apr 2019

hpayer@, mlippautz@

2019 Q2++

Motivation

2018-Q3: Latency-aware garbage collection through incremental marking

2019-Q1: Sane architecture across V8 and Blink w/ unified heap

Marking speed =

V8

dynamic language (JS)

concurrent marking

​

0.37 MB/ms

Oilpan

static language (C++)

incremental marking

​

0.19 MB/ms

(UMA; 99%-ile)

Marking (incrementally)

• Transitively visiting all children of live objects
• Bounded by live memory

time

main thread

Start

Finish

App

Step

App

Step

Step

Concurrent marking

• Transitively visiting all children of live objects
• Bounded by live memory

marking helper

Step

Step

Step

time

main thread

Start

Finish

App

App

Knock knock

Race condition

Who’s there?

▯▯▯segmentation fault

marking helper

Step

time

main thread

App

Step

App

Knock knock

Race condition

Who’s there?

▯▯▯segmentation fault

• TSAN-aware
• C++11 memory model
• Read-only concurrency on object payload
• Completely transparent; no user-facing changes

https://bit.ly/oilpan-concurrent-marking

CPU Profiling: The silent killer

Peter Marshall - V8 Tools & Embedders

Confidential + Proprietary

Confidential + Proprietary

96%

Reduction of peak memory overhead from 32.2 MiB to ~1 MiB

Confidential + Proprietary

2B+

Number of future users of the CPU Profiler

https://github.com/WICG/js-self-profiling

Confidential + Proprietary

Keep GCC running

​

2019 update

​

LG Electronics, Inc.

Jose Dapena Paz <jdapena@igalia.com> <jose.dapena@lge.com>

​

​

Chromium & GCC

• People still use GCC
• Platform specific toolchains.
• Still not ready to move to Clang.
• ...and platform c++ library:
• ABI incompatibility.
• System c++ libraries required.
• Build breaks unexpectedly
• Different interpretation of new C++ standards in GCC vs Clang.
• Subtle differences in glibc/libstdc++.
• Bugs in any of the different components.

What we are doing at LG Electronics

• Yocto build of Chromium
• Updated to Thud in march.
• use_clang=false. Using GCC 8.
• use_custom_libcxx=false. Libstdc++
• Building with Jumbo
• Hardware targets: Raspberry pi 3 (from march testing both arm32 and 64).
• https://github.com/lgsvl/meta-lgsvl-browser
• Bugfixing
• Testing x11 and ozone wayland builds
• Daily build.

Status

• Several months stalled, ...

Status

• Several months stalled, …
• But…

​

WORKING AND MAINTAINED AGAIN

​

(since 2 weeks ago!)

Thanks

Several efforts, helping with keeping GCC easy to build… Intel, Igalia, LG…

​

Thanks!

JavaScript Ecosystem

hablich@chromium.org - BlinkOn 10 Lightning Talk

Developer numbers

The estimated number of JavaScript developers world-wide is 10.7M, and it's also the fastest growing community with 3M new developers in just the last year [1].

[1] Developer Economics: State of the Developer Nation (15th Edition)

Graph copied from Developer Economics report - picture taken from report

What about B2B?

57 % of enterprise developers are using JavaScript in their job

[2] Cloud Foundry Foundation Top Languages for Enterprise Application Development 2018 - picture taken from the report

The number one criteria for choice of a programming language is the availability of libraries [3],

and JavaScript has by far the largest number of libraries available with over 650.000 packages [4].

​

​

[3] Empirical Analysis of Programming Language Adoption, Princeton, 2013

[4] State of the Union: npm

​

​

JavaScript is pervasive, it is popular on servers, edge networks, desktop and IoT.

​

​

​

​

​

Or because it is the only language that is supported by browsers. *

​

​

​

* Terms and conditions apply, might change with WebAssembly

​

​

​

​

Call to action!

Invest in JavaScript Coins now!

​

​

Hockey stick growth guaranteed!*

* The guarantee is in a state of volatility. Actually, there is no guarantee.

The End

thread text rendering

a story by fserb@

WhatWG HTML Spec in 2017

WhatWG HTML Spec in 2017

*record scratch*

​

*freeze frame*

​

Yep, that’s me. You’re probably wondering how I ended up in this situation.

Can we make text rendering

thread safe in Blink?

TSAN

TSAN happy

==

text rendering was thread safe

in a regression-safe way

Better tools enables us to do things we weren’t able to do before

Perf Testing with Puppeteer, Chrome Tracing and PMUs

Benoit Girard

Software Engineer

Facebook

How we do perf testing in the industry:

• Hardware is different
• Noise due to background execution

Developer

Perf Server

• Slow to get results
• Results are noisy
• Results are hard to debug!

Send your checkout

How we do perf testing in the industry:

​

Continuous quantities:

• Wall Time
• CPU Time

^^ Source of noise

​

Discrete quantities:

• JavaScript Code Size
• IO Operations
• # of network fetches

^^ Reproducible, countable, debuggable!

​

Can we do better!?

Can we do better!? Yes!

Developer

Retired Instruction Counter

Replace Wall/CPU Time with Instruction Counts

​

Pros:

• Accurate with 100s of threads spamming CPU & IO operations.
• More sensitive than Wall or CPU time.
• Run locally, results in seconds.

​

Cons:

• Won’t catch everything like a sleep() call.
• Requires math!

Instruction Counter Math

How many instructions can we execute?

​

Instructions = Time Budget * Frequency * Instructions per cycles * thread parallelism

​

Modern Desktop CPU ~=

Instructions ~= 1s * 2 Ghz * 1 Instruction / Cycle * 1 thread (web)

Instructions ~= 2,000,000,000 instructions

​

Each processor will have its own Frequency and Instruction / Cycle.

​

​

​

Collect using Puppeteer + Tracing

CL 1436079: Extend Chrome Tracing to collect instruction count for each block.

​

No changes to puppeteer.

​

Collect instruction counts for exactly the execution you want.

​

Easy to remove sources of noise like GC

​

Noise

1ms -> 100 μs

Where’s the noise coming from?

• Code warm-up / Code Sharing
• Lazy parsing?
• Background Parsing Thread?
• Branching on timers (setTimeout, VSync, etc…)?
• Syscall output?

​

Making branching deterministics can drive down noise further!

​

Record-replay debuggers can find noise sources.

​

​

​

​

What’s next?

Integrating it in the workflow of web engineers at Facebook

​

Exploring integration with the React Profiler.

​

​

​

Call to action

More projects using this!

​

​

​

Time

Blinkin’ Views

sadrul@chromium.org

Views: Native toolkit for the UI

Views: Native toolkit for the UI

aura::Window

views::View

views::Widget

Views: Devtools support!

--enable-ui-devtools

​

​

chrome://inspect#other

Views

• A views::Widget is the top-level container.
• The Widget manages*** the compositor (cc::LayerTreeHost).
• In aura platforms (Windows, Linux, ChromeOS), Widget does it through aura.
• A tree of views::View elements inside the Widget.
• Some of the View elements can have their own cc::Layer instances.

*** Things are somewhat different on ChromeOS. But the margin for this lightning talk is too narrow to explain.

Layer Tree

View Tree

Blink

This is how Web works too!

https://developers.google.com/web/updates/2018/09/inside-browser-part3

Interaction with Compositor (cc)

Browser

• Views holds cc wrong … sometimes.
• views came first.
• No dedicated views team until recently.
• Many performance issues with views.
• MacViews, ChromeOS.

Renderer

• Focus of cc since its inception.
• cc used to live inside WebKit!
• Lots of optimization for each step over the years.
• A large team working on it.
• As long as web exists, this will be true.
• More to come!
• Worklets etc.

Thought experiment: What if ...

Many Unknowns!!

• Oilpan in browser
• Event handlers
• Sync IPC to browser

Lightning talk

• Short
• Scary

​

• Mission accomplished

HTML5 apps on AGL

BlinkOn 10 / April 9th, 2019

(Toronto, Canada)

​

Julie Jeongeun Kim

jkim@igalia.com

Automotive Grade Linux (AGL)

• A collaborative open source project that is bringing together automakers, suppliers and technology companies
• A Linux-based, open software platform
• Hosted at Linux Foundation
• Focused on rapid innovation of vehicle software
• https://www.automotivelinux.org/

Executives from Honda, Mazda, Subaru, Suzuki and Toyota on stage together at Automotive Linux Summit 2018.

AGL members

Chromium and WebRuntime in AGL

• Igalia collaborated with LGE.
• WebRuntime
• LGE open-sourced WebOS WebRuntime solution, Web Application Manager(WAM).
• Igalia migrated it to AGL platform.
• Chromium with Wayland
• Chromium/Wayland’s worked with Ozone since last year.
• LGE supported the interface layer for WAM to Chromium.
• Igalia added ivi protocol to Chromium in AGL.

​

AGL

Chromium

Web Application

Manager

(Web Runtime)

AGL event handling

Communicating with Wayland

[memory-match]

[youtube]

[web browser]

Current status

• Web Application Manager works with Chromium68.
• Chromium68 works with upstream wayland port.
• Works on Renesas m3 board, Minnowboard, and RPi 3 which are reference target boards.
• Presented WAM Demo at CES 2019.
• AGL has Web Application Manager and Chromium at meta-html5-framework.

Plans

• Adapt WAM to new HMI architecture
• Improve the design for handling security
• Upgrade to more morden Chromium version.
• Stabilize and enhance performance.
• Make better communication in WAM, between launcher and browser.

See Jose Dapena Paz’s talk for more details!

April 10 Day 2, 13:50~14:20 Room #315

Web Technologies in Robotics and Automotive

Q&A

Lorenzo Tilve (ltilve@)

​

Jacobo Aragunde (jaragunde@)

​

Antia Puentes (apuentes@)

​

Julie Kim (jkim@)

References

https://www.automotivelinux.org

https://static.sched.com/hosted_files/aglammjapan2019/b8/AMM%20Tokyo%202019%20Intro%20to%20AGL.pdf

https://static.sched.com/hosted_files/aglammjapan2019/dd/HTML5%20apps%20on%20AGL%20platform%20with%20the%20Web%20Application%20Manager.pdf

https://twitter.com/autogradelinux/status/1103101743158755328

https://twitter.com/VStarWalt/status/1103178939927683072?s=19

https://www.slideshare.net/igalia/browsers-and-web-runtimes-for-automotive-alternatives-challenges-and-c-urrent-status-automotive-linux-summit-2018

https://github.com/webosose/meta-agl-lge/tree/flounder.chromium68

​

Chrome's Android APK Size

BlinkOn 2019 Lightning Talk

agrieve@chromium.org

APK Breakdown

android-binary-size Trybot

android-binary-size Trybot

​

Per-milestone size viewer

https://storage.googleapis.com/�chrome-supersize/index.html

​

Command-line Tool for Symbol Size Database

>>> Print(canned_queries.CategorizeGenerated())

Showing 27 symbols (27 unique) with total pss: 8152217 bytes

Sizes: .text=5.89mb .rodata=570kb .data.rel.ro=387kb Index | Running Total | Section@Address | PSS | Path

------------------------------------------------------------

0) 1868914 (22.9%) *@Group 1868914 Blink (bindings)

1) 3718254 (45.6%) *@Group 1849340 Mojo

2) 5008602 (61.4%) *@Group 1290348 V8 Builtins

3) 6118639 (75.1%) *@Group 1110036 C++ Protocol Buffers

4) 6592262 (80.9%) *@Group 473623 DevTools

5) 6914864 (84.8%) *@Group 322601 Blink (Other)

6) 7188328 (88.2%) *@Group 273464 Java Protocol Buffers

7) 7284567 (89.4%) *@Group 96239 gl_bindings_autogen

8) 7374507 (90.5%) *@Group 89940 Metrics-related code

...

Command-line Tool for Symbol Size Database

>>> Print(canned_queries.CategorizeGenerated())

Showing 27 symbols (27 unique) with total pss: 8152217 bytes

Sizes: .text=5.89mb .rodata=570kb .data.rel.ro=387kb Index | Running Total | Section@Address | PSS | Path

------------------------------------------------------------

0) 1868914 (22.9%) *@Group 1868914 Blink (bindings)

1) 3718254 (45.6%) *@Group 1849340 Mojo

2) 5008602 (61.4%) *@Group 1290348 V8 Builtins

3) 6118639 (75.1%) *@Group 1110036 C++ Protocol Buffers

4) 6592262 (80.9%) *@Group 473623 DevTools

5) 6914864 (84.8%) *@Group 322601 Blink (Other)

6) 7188328 (88.2%) *@Group 273464 Java Protocol Buffers

7) 7284567 (89.4%) *@Group 96239 gl_bindings_autogen

8) 7374507 (90.5%) *@Group 89940 Metrics-related code

...

Max Size for Low End (64.6MiB)

Max Size for Low End (64.6MiB)

600KiB of growth each milestone

Max Size for Low End (64.6MiB)

600KiB of growth each milestone

Useful Size Links

Size Bugs

Discussion: binary-size@chromium.org

APK Size Breakdowns:

https://storage.googleapis.com/chrome-supersize/index.html

​

Documentation:

//docs/speed/apk_size_regressions.md

�For Googlers:

go/chrome-apk-size

Goma is not silver bullet

What made build slow?

Takuto Ikuta (tikuta@chromium.org)

Several 10k lines of .cc files (2019 Q1)

Decoupling some very large src files in v8 utilizes goma's parallelism

• builtins-array-from-dsl-gen.cc: 50k LOC -> less than 23k LOC files
• objects.cc: 19k LOC -> less than 8.6k LOC files

made build time of d8 (v8's shell) 1.4 times faster with goma (103s -> 71s)

Unnecessary build dependency (2018 Q2)

v8's code-stub-assembler.o

build trace of chrome, many tasks unnecessarily wait finish of v8's snapshot generation

Slow linker (2018 Q2)

daily compile step time of win7_chromium_rel_ng (aka win7-rel)

link.exe

⬇️

LLD

Slow process creation in ninja (2017 Q3)

From ninja v1.8.0, per process creation overhead was improved by using vfork.

Summary

Followings made/make build slow

• Large source files
• Unnecessary build dependency
• Slow linker
• Ninja's overhead

We keep our effort to optimize build performance!

Remove Web Components v0 updates

BlinkOn 10 April 8, 2019

Yoichi Osato(yoichio@chromium.org)

What is Web Components v0?

​

​

They’re Chrome only APIs, no other browsers implement, to be ✞removed✞.

• Shadow DOM v0
• Custom Elements v0
• HTML Imports�

​

​

Project history

• 2018Q2
• Sent “Intent to Deprecate and Remove”.
• Started deprecation messages.
• 2019Q1
• ✞Removed✞!

​

☠ was broken entirely. ☠

​

(https://techdows.com/2019/03/youtube-broken-chrome-canary-74-html-imports.html)

and the patch was reverted in a day. [1]

Still many usage in wild (comparing 2018 Q2)

• Shadow DOM V0: 1.5% (-0.2%)
• Custom Elements V0: 5.0% (0%)
• HTML Imports: 2.1% (+0.1%)

​

​

Deprecation message has not inclined web authors even they’re google.

• We need some more effort.

Plans

• Migration effort.
• DevRel work.
• Reverse origin trials.
• PR Polymer.

​

• Postpone the removal until less usage.
• Define what is ‘less’ actually.
• Polymer/origin trials
• Partial removing?

So many contributors! Thanks!!

chasej@, chrishtr@, dfreedm@, dpapad@, ebidel@, einbinder@, fukino@, groby@, hayato@, iclelland@, jochen@, kenjibaheux@, kochi@, koji@, kschaaf@, lucmult@, lunalu@, mmoss@, msychev@, mwp@, pfeldman@, rbyers@, rbpotter@, tkent@, yoshin@ and more!

We are burying them!

• Shadow DOM v0
• Custom Elements v0
• HTML Imports

• Shadow DOM v0
• Custom Elements v0
• HTML Imports

Language Server Protocol for mojom

BlinkOn 10

bashi@chromium.org

​

No editor support for mojom files...

Write clients for each editor?

Mojom plugin

mojom-mode.el

Mojom extension

Language Server Protocol

The idea behind the Language Server Protocol is to generalize how editor/backend communicate, so a single server can be re-used in multiple editors

https://microsoft.github.io/language-server-protocol/overview

Language Server Protocol to share logic as much as possible

LSP Server

LSP Client

LSP Client

LSP Client

Mojom LSP

• Syntax check (no semantic check yet)
• Goto definition

Emacs Demo

VSCode Demo

Chrome Status Summaries for Web Developers

Announcing: Blink Intent Process Crash Course

Yoav Weiss

Joe Medley

​

Proprietary + Confidential

Proprietary + Confidential

Proprietary + Confidential

Fonts Highlights

BlinkOn 10, Toronto

Lightning Talks Day 1

​

Dominik Röttsches�drott@google.com

​

​

​

Native support for AAT Fonts

​

Font Matching Improvements

AAT - State Machine

OpenType - GSUB Lookup Tables

html5-full-render on Mac

HarfBuzz AAT Speed-Up (over CoreText backend)

Thanks, @behdad, @ebraminio!

Font Matching Improvements

Family Matching

“Local Matching”

Resolving src: local(<name>)

Google Fonts on Android

• Google Fonts uses src: local() sources as speed-up when local version is available
• Without correct src: local() matching �Google Fonts speedup ineffective

Summary

• Native AAT support in HarfBuzz brings 3-12x improvements in AAT shaping performance
• Src: local() fix allows better selection of pre-installed fonts on Android and other OSes

​

RTCQuicTransport Web API

Seth Hampson

shampson@chromium.org

Motivation

• Low level & high performance data transport in the web
• Modern API
• Incorporates send-side backpressure
• “Next Version” WebRTC effort
• Lower level components
• No SDP!

Overview

• Exposes QUIC connection & QUIC streams
• Peer to peer
• Uses the ICE protocol for P2P connection
• Standalone (no RTCPeerConnection stack)
• Built in encryption and congestion control

File Transfer Demo :)

So, what’s next???

Future

• Origin Trial in Chrome 73 - 75
• Looking for developer feedback
• WHATWG streams
• Datagrams
• Discussion
• Client/Server API without ICE
• Generic data transport API
• Moving to WICG
• Come talk if you want to get involved!
• shampson@chromium.org
• steveanton@chromium.org
• See blog post

​

Thanks!

What LUCI gives us?

What is LUCI?

Layered

Universal

Continuous

Integration

Lucy

Swarming

Buildbot is gone!

What is LUCI?

Micro services

before it was cool

Serverless

before it was cool

TL;DR: Scale, lots of it

Blink is a lot of tests

Chromium is a lotter of tests

14 years, per day

On 14 000 workers

Size of tests

binaries last year?

(compressed)

10TiB?

100TiB?

9.3PiB!

300 TiB of I/O per day

Compressed.

Secret sauce?

Reproducible environment

Key points

• VMs recreated daily
• Content addressed inputs and outputs!
• Reproducibility
• Horizontal scaling
• Strong security and audit

Users

• Chrome, ChromeOS and satellite projects
• Fuchsia
• Google Home
• Nest
• Stadia

… and others

Thanks!

Chromium Slack

• Available at https://chromium.slack.com/
• Open forum for discussions around Chromium development
• Replacement for #chromium / #blink channels on IRC
• If you don’t have a @chromium.org account, send an email to chromium-slack-invites@chromium.org

Why?

Feedback?

If you don’t currently use Slack, but you would if:

• it didn’t require a separate account
• it didn’t require 2FA
• it didn’t require being a Chromium developer
• <insert reason here>

Please talk to dcheng@chromium.org!

(๑>ᴗ<๑)

See you tomorrow!

(๑>ᴗ<๑)

*

*

*

*