One of the common questions I see about the rapid release schedules for the browsers (every six weeks or so for Chrome and Firefox) and even Windows-as-a-Service (Edge has a major update every six months) is, "how can the developers make large-scale, high impact changes if they break everything up into small chunks?" Firefox 53, released yesterday, and Edge 15, released as part of the Windows 10 Creators Update, show us how it can be done.
Mozilla is planning a major overhaul of its Gecko rendering engine to make it both safer and faster. This work is being done under the name Project Quantum.
When Gecko was first developed, webpages were largely static, simple things, and computers were mostly single core. The only time that GPU acceleration was used was when playing a game or some other 3D application. But today, pages are dynamic and complex, computers have lots of cores and simultaneous threads, and our GPUs are used all over the place. Not only is the browser itself now a 3D application (thanks to WebGL), but GPUs are being used to accelerate 2D content as well.
Project Quantum is how Mozilla plans to adapt for this new age. Mozilla is using its safer Rust programming language for parts of Quantum. The company has an experimental rendering engine called Servo that's written in Rust, and pieces of this will make their way into Firefox. The initial focus will be on updating those parts of Gecko that are most amenable to parallel or GPU-based computation, and Firefox 53 contains the first element of this. Firefox 53 will (for most people; it requires Windows 7 with the Platform Update, or better, plus a GPU that isn't blacklisted) create a separate GPU process that's used to perform compositing. The compositor process takes the different elements of the page and the Firefox window and merges them together to create the finished product.
This GPU process has been enabled in Mozilla's beta and nightly builds for some weeks. As well as being an important piece of groundwork for Quantum, Mozilla has found that creating this GPU process has improved the stability of the browser. GPU drivers still crash more often than anyone would like, and prior to creating a separate GPU process, a 3D driver crash would bring down the browser in its entirety. Now, the GPU process can crash without taking down the rest of the browser.
Apart from a slight stability improvement, the only change most people should notice from this work is that there's an extra firefox.exe process listed in Task Manager.
Firefox 53 does bring some more visible changes, however, with the inclusion of an attractive new theme. It's a compact theme available in both a dark and a light version.
Microsoft's work on Edge is motivated by some of the same concerns behind Project Quantum. A central element of the browser is something called the DOM (document object model). The DOM is the programmatic interface that bridges HTML—the tags and elements on the page—with JavaScript. JavaScript code manipulates the page by manipulating the DOM.
The Edge DOM code was initially based on the Internet Explorer DOM code, built for a time where pages were mostly static. The way Microsoft implemented the DOM made a lot of sense at the time, but as pages have become more dynamic and complex, the company has found that its old approach has grown excessively complex, hurting performance and being a source of bugs. In a detailed post, the Edge team has described how the DOM used to be, and how it works now.
The end result of this work is faster performance when manipulating the DOM and fewer bugs in the code. The DOM went from causing about 28 percent of all reliability bugs to about 10 percent.
Project Quantum is, obviously, a huge undertaking; much more than can be done in one six-week cycle. So Mozilla has broken it up into smaller, distinct pieces that are developed and tested in the beta channel before being pushed into the stable channel. Even in the beta channel, users are randomized, with some using the new code, some sticking with the old code, so that stability and performance can be measured and compared.
Like Project Quantum, replacing the Edge DOM is a huge piece of work, more than can be done even in the six months between Edge releases. So development was broken down into phases; first defining a cleaner API for the DOM that ensured that the browser never depended on specific aspects of the way the DOM was implemented, then migrating all code to use this new API, and only when that was done was the DOM code itself replaced.
This work was done across multiple versions. Migrating to the new API was done in Edge 12 and 13. The new DOM was deployed in Edge 14. With the new DOM in place, Microsoft has been able to optimize and improve parts of the engine that sit around the DOM.
In the past, with its infrequent "big bang" releases, Microsoft might not have gone this incremental route. The company might instead have tried to develop the new DOM and integrate it into the browser in a single step. This is, after all, how much of Windows was developed prior to Windows 10: Microsoft had lengthy development periods, followed by integration, testing, and fixing periods. But the new DOM shows that this is not the only way, or even the best way, of developing substantial new features. As Mozilla and Microsoft are both showing, incremental development and regular releases are, in fact, compatible with major architectural changes.
reader comments
54