We have:

- Stylo, built by default, off by default

- Webrender, built by default, off by default, current pref makes it render things through both engines.

- rust-url for url parsing, built by default, off by default, current pref makes it parse through both parsers and compare. I intend to bring this across the finish line once done with stylo

- encoding_rs for dealing with string encodings. built and on by default. Not exactly a servo component (servo used to use rust-encoding), but i think servo uses it now.

A GitHub search suggests that Servo isn’t using encoding_rs.

There is a wiki page about Project Quantum: https://wiki.mozilla.org/Quantum

Currently Quantum CSS (Stylo) and Quantum Render (Webrender) are both in Firefox Nightly, but they are unstable and can cause really bad performance, especially Quantum Render. They won't be done until at least Firefox 57 and some most likely later.

Quantum Compositor is in Release already I believe. It's the out of process compositor for Firefox.

Changes from Quantum Flow are continuing to be implemented into Nightly and later on Beta.

I haven't ready much about the progress around Quantum DOM, and I have no idea for which release it is targeted.

Do I get this right.

Servo is the experimental browser (engine?)?

Quantum is the project that ports parts of Servo to Firefox over time?

Quantum is now also a bit of an umbrella project for initiatives making Firefox faster. "Quantum Flow", for example, is an engine-wide effort to push performance in the bits that still C++.

Right. Servo is an engine that will be embeddable into apps that need to render HTML, not just browsers.

Ah, so like the omni-present webkit view?

Yeah, exactly. It doesn't include a JS engine so for now it uses SpiderMonkey, but eventually you should be able to plug others in.

Whoa I didn't know webrender was shipping on nightly already, even if it's unstable.

Currently with Webrender enabled Firefox renders it both on Webrender and the old renderer which causes it to be really slow.

I see, that would explain the performance issues. Why is it set up like that?

There's a lot of refactoring to do in Gecko's graphics stack to fit the new rendering model. While they do that, they can also accelerate one thing at a time with WebRender, testing incrementally. Things like SVG which WebRender doesn't have yet, can also use the old system and be included in WebRender as images.

The old system will still be needed post-WebRender for printing at the very least.

> The old system will still be needed post-WebRender for printing at the very least.

Isn't it possible to take a frame from WebRender and print that? Having two separate systems seems like allot of unnecessary maintenance. Especially if one of those systems is only used on rare occasions like printing.

My understanding is that WebRender doesn't support everything yet, so right now it's mostly about validating correctness.

Ah I see, so it basically enables a parallel run of webrender to gather compatibility/correctness stats.

So it renders it two times and compares the results?

It renders it in series -- stuff goes through webrender first, and then whatever webrender couldn't handle gets dealt with with the regular renderer.