-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Work items for new contributors
I've put together a brief list of interesting tasks for new contributors to servo to work on. These are things that are relatively self-contained, feature-oriented and don't require solving a too many difficult design problems beforehand. Some of them are focused on a clear goal and some are more open-ended. For each I've included a brief description and a link to more information. If you are interested in taking on one of the features then I recommend mentioning so on the appropriate bug tracker issue so that others have some visibility into your efforts. I've also updated the roadmap with these items.
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
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 may have 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. This is concerned with memory caches, not disk.
https://github.com/mozilla/servo/issues/238
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. We probably want to start this work by creating bindings to NSS and seeing what other libraries and techniques it forces on us.
https://github.com/mozilla/servo/issues/239
The various DOM classes (under dom/) are full of stub methods right now. Using the relevant specification and Gecko as reference, we need to start implementing the real behaviour that is required. There is a work-in-progress list of implementation priorities here: https://github.com/mozilla/servo/wiki/Priority-of-DOM-implementation
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 timer 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
Both Gecko and WebKit have extensive test suites. Pick one set of tests, write a test harness for servo, integrate it into the build. Repeat. I imagine there are various independent conformance test suites out there as well that we can adopt. This can take as much or as little effort as you feel like, until we are running all the tests in the world.
https://github.com/mozilla/servo/issues/242
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. This is a large task but must be done - libcss is n
The current CSS code uses its own string interner. Part of this task will be to unify our CSS string representation with our Rust and JS ones.
https://github.com/mozilla/servo/issues/243
Right now there is just enough CSS implemented to make a few simple demos. This is an open-ended task of identifying useful bits of CSS and implementing them. It will entail figuring out how to extend our CSS bindings to parse and calculate the properties, modifying layout, the display list and renderer as appropriate.
There is a list of prioritised properties here:
https://github.com/mozilla/servo/wiki/Priority-of-CSS-properties
Implement various Android-specific features. Update the build system for cross-compilation, add support for Android's font subsystem.
On Android we particularly want to explore off-main-thread texture upload, as that is a major source of latency on Mobile Firefox. Essentially, instead of blocking the main thread to put textures on the GPU, we should do so on a worker thread. Unfortunately, the mechanisms to do so are very hardware-specific. There's a GL call named EGLImageKHR that could be helpful, but pure DMA might be even better.
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.