After many months of hard work and preparation, I’m pleased to announce the general availability of WebRender for selected Windows 10 devices. WebRender is a major rewrite of the Firefox rendering architecture using the same kind of GPU-based acceleration techniques used by games.
Until now, our browser rendering pipeline varied depending on the platform and OS. This has a number of drawbacks:
WebRender replaces this with a modern, unified architecture which consists of two major elements:
For more details, refer to Lin Clark’s excellent Hacks article.
This design provides very fast throughput and eliminates the need for complicated heuristics to guess which parts of the website might change in future frames. Moreover, a single backend that we control means bringing hardware acceleration to more of our users: we run the same code across Windows, Mac, Linux, and Android, and we’re much better-equipped to work around driver bugs and avoid blacklisting. It also moves GPU work out of the content process which will let us have stricter sandboxing in the content process.
We’ve seen significant performance improvements on many websites already, but we’ve only scratched the surface of what’s possible with this architecture. Expect to see even more performance improvements as we begin to take full advantage of our architectural investment in WebRender.
Since WebRender was quite a large undertaking, we decided to split up the release across a number of smaller targets. The aim of today’s release is to ship a WebRender MVP (minimum viable product) to one target; we plan to learn from that, and then gradually ship WebRender to additional platforms. This release of Firefox 67 will see us roll-out WebRender to users running Windows 10 on desktop machines with NVIDIA graphics cards. This currently represents approximately 4% of Firefox’s desktop population.
The go-live date for Firefox 67 is Tuesday, May 21st at 6am PST. WebRender will ship disabled by default. On May 27th, 25% of the qualified population will have WebRender enabled. We will then increase that rollout to 50% by Thursday, May 30th – assuming that everything is going smoothly. WebRender will then be enabled for 100% of the qualified population by the following week.
We will be keeping a close eye on various health metrics to ensure everything is working as expected. We also plan to conduct an A/B test to compare performance against non-WebRender-enabled Firefox instances in release. We have spent the past several months putting WebRender through its paces in Nightly and Beta and even conducted an experiment in the Firefox 66 release to help uncover any potential bugs and issues we might face.
This milestone is a significant one, and we are excited to get here! A big congrats goes out to everyone on the Graphics team and all of those who have pitched in to help us get to this point. We are all looking forward to shipping WebRender to more users throughout the rest of this year.
When it came to performance, our main goal for the MVP was to avoid regressing performance or correctness vs. making it wildly better right away. That said, during our experiments in Nightly and Beta, we’ve observed that users with WebRender experience less jank, and that a number of website performance problems disappear. We will keep a close eye on our metrics as we ship throughout Firefox 67 and will report back on how things are looking in Release.
We are also continuing to prioritize performance work in WebRender. Picture caching 2.0, various display list improvements, and document splittingare all enhancements that leverage our flexible, new architecture to speed things up further.
There are a couple of reasons why we choose to ship WebRender first on Windows 10 machines with NVIDIA graphics cards. This is the platform where we currently have the best performance with WebRender, and we wanted to compete with our flagship graphics experience to prove that this was a better architecture. Also the percentage of Firefox users with this combination in release (approximately 4%) is a safe number such that we don’t introduce too much risk for this first milestone.
Feels like y’all have been talking about WebRender for a while now. Why has it taken so long?
In short: computers are hard.
WebRender started as an experiment in the Servo research projectand as such, only needed to support a small number of use cases. Integrating WebRender into Gecko meant that we had to build on that and account for the multitude of variables possible to encounter in sites on the web today. As I am sure you can imagine, that has been no small feat.
Replacing the browser’s existing rendering engine is a task that required careful consideration, planning and thoughtfulness. We have basically been performing open heart surgery on a living, moving beast (that wasn’t put under anaesthesia).
The good news is that we have learned quite a bit throughout this process and are confident in our plans going forward when it comes to continuing to ship WebRender this year.
We currently have WebRender enabled in Nightlyfor:
To turn on WebRender, go to about:config, enable the gfx.webrender.all pref, and restart the browser. Note:doing so may cause pages to render incorrectly, your browser to crash, or other problems. Proceed with caution!
The best place to report bugs related to WebRender in Firefox is the Graphics :: WebRendercomponent in Bugzilla.
Why, thank you! Our goal is to ship WebRender out to more users throughout the year while continuing to make it more performant. Our top priorities for the next few months will be the following:
We got together in Toronto in early April and created a high-level roadmap.
We will keep everyone posted as our plans develop.