In 2012 we started an ambitious project to develop a new browser engine that would deliver excellent performance on embedded devices and consumer electronics. Mobile phones aside, consumer electronics products are usually designed with the smallest possible bill of materials required to deliver the desired user experience. A good example of this type of product is the TV Set Top Box (STB), these are often cost subsidised by TV network operators and in some cases are given away free.
Since consumer electronics product designers are always striving to get the best performance they can from every component they use, we set ourselves the goal of delivering significantly higher performance than any other browser could offer. This wasn’t a naive aspiration, in the 6 years prior to starting the project, we’d developed the world’s fastest SVG engine and had significant experience in managing a rapidly evolving browser product base from our work with WebKit.
Mainstream STB silicon was just starting to include a GPU. It was clear, even at that time, that the GPU would soon become commonplace in CE silicon so we decided to execute all our rendering code on the GPU. Efficiently using the GPU offers the prospect of high frame rate animations and smooth UI transitions which were notoriously difficult to achieve on an STB. Also, running the rendering code on the GPU helps ensure CPU availability for all the browser’s non-rendering tasks.
Back then, single core CE silicon was also just starting to be replaced with dual core. Whilst each individual core was often a little slower than the single core product it replaced, overall processing power increased. It seemed logical to assume CE developments would continue down this evolution path, following the footsteps of the more powerful desktop processors which were already well into multicore territory. We focused our ideas for a multithreaded layout engine to match this multicore trend.
Some of our early thinking was shaped by the parallel web page layout research done by Meyerovich & Bodík. That research also influenced the Servo project which was started by the Mozilla foundation around the same time that we started developing our multithreaded browser.
Writing multithreaded software has its own unique set of challenges to ensure two threads don’t both manipulate the same data structure at the same time. Careful design ensures that laying out text in one part of the DOM tree has no requirement to access another part of the DOM tree. We strictly adhere to this practice which has helped ensure thread safety by design. Using ThreadSanitizer (TSan) as part of a continuous build system, coupled with automated stress testing on a variety of machine loads has helped ensure a mature code base where any threading issues are quickly spotted and addressed.
The first release of our multithreaded browser, Flow, was announced on 1st May 2018. As we’d hoped, Flow’s animation performance on multicore CE silicon outperforms WebKit and Blink. We now have the big task of implementing the rest of the features expected in a modern browser.
If you’d like to automatically receive our posts by email please join our mailing list.
