-------- Original Message --------
Subject: Introductory work items for servo contributors
Date: Fri, 04 Jan 2013 17:09:22 -0800
From: Brian Anderson <bander...@mozilla.com>
To: dev-se...@mozilla.com, kyeongwoon....@samsung.com,
ily...@gmail.com, sh4....@samsung.com
Greetings, folks!
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.
[roadmap]: https://github.com/mozilla/servo/wiki/Roadmap
# Image decoding
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
# Unified cache infrastructure
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
# Write an HTTP client library
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
# Port the Paris DOM bindings generator to Rust
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
# Performance instrumentation
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
# Port existing test suites to servo
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
# Rewrite CSS code in Rust
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
# Implement more CSS properties
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
# Android
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.
# Local storage
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
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo