As requested, here's the state of Servo as it stands.
We have a GitHub repository here: https://github.com/mozilla/servo
Currently what we have builds on Mac and Linux. There's no fundamental
reason why it won't work on Windows, but none of us have put in the
effort necessary to bring it up. The sole platform ("widget" backend in
Gecko terminology) is SDL, but there's an in-process planned move to
GLUT, which should land when the Layers infrastructure is ready. We're
undertaking this move because the Mac port of GLUT is maintained by
Apple and much higher-quality than the Mac SDL port. Neither of these
backends are intended to be long-term solutions; for production we will
want true platform-native backends for each platform.
We make heavy use of Git submodules for modularity--like WebKit, we want
the pieces of Servo to be independently hackable. In addition, we'd like
the components of Servo to be reusable for general Rust apps. For
example, networking, URL parsing, and layers are useful functionality
for a variety of applications, and we can benefit from community
contributions to these components when and if Rust becomes widely used.
Where possible, we reuse existing C and C++ libraries. This doesn't
preclude the possibility of rewriting the functionality provided by
these libraries in safe and parallel Rust code, but it helps us get off
the ground. At the moment, these libraries are:
* HarfBuzz (and its dependency Ragel), for text shaping.
* Azure, for 2D graphics.
* SDL (soon to be replaced with GLUT), as an abstraction layer over the
native windowing system.
* stb_image, for image decoding. This is a very simple image library,
likely insecure and missing support for progressive JPEG, but it's
extremely small and simple, devoid of dependencies, and in the public
* libuv, for networking. This is a library closely associated with
node.js, which abstracts over the asynchronous I/O mechanisms on each
platform. Most notably, it works on Windows, unlike nearly all of the
Our focus so far has been on laying the proper groundwork for a scalable
rendering engine. In particular, we've been focused on decomposing the
rendering pipeline into tasks (lightweight Rust threads), as this is the
part that's most critical to get right and the most difficult to
retrofit onto existing architectures. Right now, Servo has several tasks
in the rendering pipeline. (When we get tab/window support, each of
these tasks will be replicated for each origin.) As I understand it, the
manages layout task lifetimes. DOM structures are shared between this
task and the other tasks in a read-copy-update model; if content
concurrently mutates a DOM node that layout is currently operating on,
that DOM node is copied for the duration of that layout operation.
* A layout task, which supervises layout. Currently, layout is mostly
done sequentially, but our intern Margaret Meyerhoffer has begun to
implement parallel CSS selector matching. Conceptually, the layout task
is one supervisor task with many subtasks to perform parallel layout. At
the moment, this task can perform both toy inline and toy block layout.
* A renderer task, which receives display lists and renders them. When
layers infrastructure lands, there will actually be many renderer tasks,
one for each layer. This will allow us to render layers in parallel.
* A platform task, which manages the main OS thread and native platform
event loop. Nothing happens on this task except for that which
absolutely needs to be handled by it (because the native windowing
library demands it).
* An engine task, which supervises the other tasks and does nothing else.
* An I/O task, which handles networking in an evented, asynchronous
manner via libuv. Note that networking is not yet implemented in Servo,
so this task doesn't do much.
Another major planned task (not yet implemented) is:
* A compositor task, to composite layers together. Scrolling and CSS
animations should be handled by this task as well.