EXPERIENCES ADOPTING EFL IN SERVO (A NEW WEB BROWSER ENGINE)

Lars Bergstrom Mozilla Research

Why a new web browser?• Support new types of applications and new platforms

• All modern browser engines (Safari, Firefox, Chrome) originally designed pre-2000

• Coarse parallelism

• Tightly coupled components

• Vast majority of security issues are related to the C++ memory model

Servo• Architected for parallelism

• Coarse (per-tab), ala Chrome

• Lightweight (intra-page), too

• Written in a memory-safe systems language, Rust

How a browser worksHTMLCSSJS

DOM Flow Tree

Display Lists

Script

Styling LayoutParsing

More details: https://github.com/larsbergstrom/papers/blob/master/icfp15-servo-submitted.pdf

Script & Interactions

Layers

Rendering

FinalOutput

Compositing

How a browser worksHTMLCSSJS

DOM Flow Tree

Display Lists

Script

Styling LayoutParsing

More details: https://github.com/larsbergstrom/papers/blob/master/icfp15-servo-submitted.pdf

Script & Interactions

Layers

Rendering

FinalOutput

CompositingEcore?

How a browser worksHTMLCSSJS

DOM Flow Tree

Display Lists

Script

Styling LayoutParsing

More details: https://github.com/larsbergstrom/papers/blob/master/icfp15-servo-submitted.pdf

Script & Interactions

Layers

Rendering

FinalOutput

CompositingEcore?

Evas?

Rest of this talk• Toolkit investigations

• Suitability of Ecore

• Attempts to build it

• Attempts to write a Rust wrapper

• Graphics exploration

• Evas as a flow tree replacement

• Evas as a display list replacement

Toolkit requirements in Servo• Open a window

• Handle mouse/keyboard/etc. events

• Raw graphics buffer handles

• Bonus points for cross-process secure APIs

• Multi-platform

• Linux, OSX, Android, Linux embedded, Windows, X11 remote, MESA

How does Ecore measure up?

Toolkit Window Events Raw Secure Platforms

Ecore Yes Yes Yes Yes ?

SDL Yes Yes Yes No Yes

Glut Yes Yes Yes No No

Glfw Yes Yes Yes No No

Glutin Yes No Yes No No

Using Ecore• Packages missing or massively out of date

• Occasional packages on various Linux distros, all at least 2 versions old

• Homebrew (for OSX) were even older, basically just called configure and died due to lack of dependencies

• Android…

Building Ecore“I found the libraries to be pretty intimidating. Whilst it seemed like they were going for a modular approach, in practice you needed tons of dependencies, and needed to opt out of lots of seemingly unnecessary things. I mean, why on earth does one need *bullet physics* or freetype in a context creation/input library? And turning stuff off caused harsh rebukes on the IRC and from the build system itself. And for something that is meant to be cross-platform, the experience on OS X was pretty bad - apparently only one person was working on it, and they weren’t a regular committer.”

Bad times on IRCA - why don't you just follow the wiki page A - that already explains everythingy ou need to do

B - that page is 6 months old B - I have no idea who wrote it

bjz searches for osx in the wiki search bar - "No search results”

A - bjz, btw, update the wiki page if you see anything wrong there

Better times on IRCbjz -yeah, we handle the opengl calls and font rendering and all that C - and once you know a click happened, you have your own stuff to know where that click happened C - so from a very basic point of view, you'll have an Evas canvas with an image taking the whole thing where you'll draw with your own stuff C - and you want to listen to ecore_input events and pass them to your own handlers bjz - C: ok bjz - C: awesome, this is helpful

Wrapping Ecore in Rust

“And creating bindings for it was a pain. If you wanted to do I high quality wrapper like I normally do, you virtually had to wrap a large portion of the library… all the custom datatypes and object system… “

Now… Graphics!• Browser terminology

• Flow tree - the actual boxes/fragments resulting from applying styles to the DOM nodes

• Display list - hierarchical (z-index-respecting) lists of positioned elements

• Layers - content rendered into memory or GPU buffers

Challenges with replacing the flow tree

• Specifications are quite persnickety about the final display

• CSS 2.1 17.6.2.1 Border conflict resolution“The rule of thumb is that at each edge the most "eye catching" border style is chosen, except that… “

• Also quite particular about stacking orders

• CSS 2.1 Appendix E Stacking Contexts“The painting order for the descendants of an element generating a stacking context…” followed by 10 steps, with up to 19 substeps each

So, how about that display list?• Just a few items (even when Servo is complete)

• SolidColor, Text, Image, Border, Gradient, Line, BoxShadow

• Challenges

• Serialize these across processes so that we can isolate the graphics drivers (insecure) from the content and script

• Do we still get benefits if the animations, etc. are at a higher level?

QUESTIONS?larsberg@mozilla.com