Servo – Render in parallel
github.com
github.com
What is exciting about this in the context of Servo, though, is that it completes the parallel pipeline:
* Script can be parallelized through PJS or Web Workers.
* All phases of layout are fully parallelized: selector matching is performed in parallel (one micro-task per DOM node), layout is performed in parallel, and display list construction is performed in parallel (one micro-task per render object).
* Painting is now performed in parallel on a tile-by-tile basis.
* Compositing is performed in parallel thanks to the GPU.
All of these tasks can also be performed in parallel with one another.
I hope the Servo team is acquainted with the video game world, and the curious optimizations that have been taken in that realm to greatly improve performance in multi-threaded settings.
I'm not affiliated with Mozilla or Servo but from the information on the Servo page and the number of Acid2 and other issues they're tracking, it's clear that there's still plenty of work to do. Throw in the fact that the Rust language itself is targeting the end of the year before they hit version 1.0 and you'd have to guess that Servo as a separate project likely has minimum 6 months (more likely a year) before they examine whether it's successful enough to start integrating with Firefox.
Then they'd need to integrate and test.
Think about how long the new "Australis" UI was in development (more than 2 years). It was just a user-interface change without changing programming language or other dev-tools.
The renderer is the core of the program. And integrating Servo would involve integrating and testing a new language along with the new code. I doubt a large, capable team could perform that much integration and testing in under 12 months – even after Servo itself was considered "complete" (which it isn't).
My prediction: a release of Firefox with Servo code is 2 years away or more (assuming Servo is considered a "success" in 6-12 months).
I'm not sure if that's still the plan, however.
I think the biggest improvements may come from experimenting with new asynchronous DOM APIs, which the browser can intelligently batch up for performance. Unfortunately, web developers will have to use these APIs for them to have any effect, and it seems to be a long way away right now for real world use. But it's part of what Servo will be helping to explore, as I understand it.
It would be very interesting to survey the largest projects being developed on Github to determine if they've also grown bespoke ways of dealing with the platform's pain points. I know that the Rust developers aren't entirely satisfied with the tools that Github provides (which seem to be optimized for small projects at the expense of large ones), but Github's network effects are just too good to ignore for a project that relies on volunteer contributions.
Definitely, you easily hit its limitations with big projects:
* the commits view is completely useless if development is highly branchy (although to be fair that's the case for pretty much all git history visualisation tools)
* the CI integration (statuses[0]) is very limited with only 4 states (pending, success, error and failure) and doesn't work OOTB with merged heads
* issues-filtering tools have odd cases when you're trying to e.g. filter by multiple tags
* and they're not available at all the PR list
* the notifications system is insufficient and incomplete (IIRC you're not notified when assigned on an issue or PR…)
* the teams integration is lacking (essentially, teams are only very broad ACLs, you can't triage issues to teams so you have to use tags, except when you start doing complex queries involving multiple tags it all breaks down)
It was Word.
Or it was 3D Pinball.
The issue was Word and 3D Pinball didn't use multi-cores well and some people didn't see anything to gain. They thought "well it isn't going to make lag in Word disappear, or Pinball more fun." They completely missed that they could run both at the same time now.