[Brakenshire]

One thing I've been wondering is that Stylo and Webrender can parallelize CSS and Paint, respectively, but I haven't seen any mention in Project Quantum (the project to integrate Servo components into Firefox/Gecko) of any component to parallelize layout, which is probably the biggest bottleneck on the web at the moment.

Is parallel layout something which can only be done through a full rewrite, hence with Servo, and bringing Servo up to full web compatibility, or can this be handled through the Project Quantum process, of hiving off components from Servo into Firefox?

[Manishearth]

Integrating layout is a lot more challenging.

Now, once stylo and webrender are in play, ideally layout can just fit in between. All the interfacing already exists from Servo.

However, there are a lot more things in Firefox that talk to layout. This would need work, more work than Stylo.

But this isn't the major issue. The major issue is that Servo's layout has a lot of missing pieces, a lot more than was the case with its style system. It's hard to incrementally replace layout the way webrender did with rendering (fall back when you can't render, render to texture, include it).

So it's doable, but a lot more work.

[kibwen]

The OP links a video from 2015 that implies that one of the advantages of making Stylo the first Servo component in Gecko is that the next phase in the pipeline, layout, will be able to benefit from having a well-defined interface in place. I'm curious about this as well!

[bholley]

Since I gave that talk, it's become more clear to me that servo's layout engine is a lot farther from feature-complete than the CSS engine was. So my hunch is that the granularity of incrementalism we used for stylo may not be workable for layout.

That said, we are absolutely going to explore opportunities for more Rust/Servo in layout, so we just need to find the right strategy. One incremental step I'm interested in exploring is to rewrite Gecko's frame constructor in Rust using the servo model, but have it continue to generate frames in the Gecko C++ format. This would give us rayon-driven parallelism in frame construction (which is a big performance bottleneck), while being a lot more tractable than swapping out all of layout at once. Another thing to explore would be borrowing Servo's tech for certain subtypes of layout (i.e. block reflow) and shipping it incrementally.

Each of these may or may not share code with Servo proper, depending on the tradeoffs. But Servo has a lot of neat innovation in that part of the pipeline (like bottom-up frame construction and parallel reflow) that I'm very interested in integrating into Firefox somehow.

We're going to meet in Austin in a few weeks and discuss this. Stay tuned!