-
Notifications
You must be signed in to change notification settings - Fork 0
Roadmap
So there's a lot to do. We'll try to outline the work here, with links to relevant bugs.
Some general goals for the near-term:
- Demonstrate good performance at tasks that are hard for other engines. Servo aims to have better latency and throughput than existing engines in modern workloads. We need to identify these scenarios, create test cases, and orient our work towards implementing them. Latency is particularly important for user experience demos; throughput is good for benchmarks.
- Implement the entire Servo architecture, including a multi-process front end. Although true sandboxing is not a near term goal, we want to design Servo's interface for sandboxing, and being multi-process from the start will make that easier.
We have discussed milestones in the past. We may want to revisit ideas for milestones and dates, e.g. display Wikipedia, pass Acid1.
DOM and display list type safety; refactoring; test suite; bots; navigation
There are many caches all up and down the browser stack, for things like images, fonts, glyphs, text runs, and numerous unimagined future things. Additionally servo often has dual caches for any particular thing, one remote cache in a dedicated task and another task-local cache. As control over memory usage is critical in web browsers we should plan on making this robust from the outset.
https://github.com/mozilla/servo/issues/238
Servo doesn't have any local storage. This will be needed for history, bookmarks, caching and a million other things. At this time we are inclined to use LevelDB for everything, so a good place to start would be LevelDB bindings. Then move on to some of the common browser features and figure out how to integrate them into the engine.
https://github.com/mozilla/servo/issues/244
navigation
interface design, content deals with a lot of messages to and from different sources. needs a clear strategy. how are DOM events sourced and routed? likewise input events? various parser message flows.
- make sure all parsing is asynchronous. we should never (or rarely) be blocking on parsing
- parse inline JavaScript and CSS
- Get basic JavaScript support up and running, enough to implement simple animations and the like. Get
onclick
working. Maybe navigation too.
-
We need the beginnings of a non-toy, production DOM.
-
This may depend on some Rust work to implement safe single inheritance. We can use unsafe code in the meantime.
-
We need to decide how much copy on write (COW) we want to do. pcwalton and brson are beginning to think that COW should be shelved over complexity and performance issues.
-
Gecko uses a very advanced system for generating DOM bindings from WebIDL (the Paris bindings), developed through years of experience. It is apparently very good, so we should adopt it for servo as well. https://github.com/mozilla/servo/issues/240
-
We need floats to pass Acid1 and to render most Web content.
Our current image-decoding library, stb-image, is slow, not suitable for a web browser. We need our own image decoding library, initially based off existing high-performance decoders, and expandable to Rust-based decoders later.
https://github.com/mozilla/servo/issues/237
We have very primitive HTTP support, built upon the Rust standard library and the Joyent HTTP parser. Needs a lot of work. It can be a rewrite as the existing design is poor. It's probably best to start by binding NSS since it will impose some implementation restrictions.
https://github.com/mozilla/servo/issues/239
We need to be able to make repeatable performance measurements of various kinds. There is very minimal code for this already in servo in the form of a time function, but we need much more. We want servo designed for gecko-style telemetry from the beginning, so it would serve us well to do some up-front investigation into what they are doing.
https://github.com/mozilla/servo/issues/241
rust-css is our CSS parser and selector matching library. It is currently a thin wrapper around NetSurf's libcss library. Ideally we can rewrite this in two phases - first the parser, then the selector matcher, but they may be too intertwined for that to be a viable strategy.
https://github.com/mozilla/servo/issues/243