For a while now, people have been expressing concern about Chrome’s dominance creating a browser monoculture. With Microsoft’s recent switch to Chrome, the choice of rendering engine was effectively reduced to Blink (Chrome), WebKit (Safari) or Gecko (Firefox). Whilst there are a large number of browsers for desktop and mobile users out there, almost all are based on Blink/Chromium.
As well as displaying web content, HTML browsers are used in a wide variety of products for application and user interface rendering. The potential effect of one company dominating the implementation of the standards is that they are biased towards web page rendering, their largest use case. Focusing solely on web content could limit the wider appeal of HTML.
Domination stifles innovation
All three main browser engines are developing at a rapid pace, but some aspects have barely changed since they were first written. Blink, WebKit and Gecko are based upon layout architectures which are single threaded, with some aspects dating back to the nineties when single core processors were commonplace. Being single threaded means that the rendering engine isn’t making full use of multi-core processors.
Today’s browsers now use a multi-process architecture where each page can be allocated its own process. The multi-process model means that if any one page stalls, the others are unaffected, but it does little to improve the performance of single page rendering. Unfortunately, for user interfaces, it is single page performance that matters and the restrictions of single threaded layout can impact the user experience.
For most people with fast computers or phones, layout speed on the open web is fast enough. Because of this, there is little motivation to make large scale architectural changes to improve layout performance, especially when these changes would disproportionately benefit the minority use cases.
Moving beyond a single thread
During the last ten or so years, various groups recognised the limitations of a single threaded architecture, but developing a multithreaded browser isn’t a straightforward task. Multithreaded layout is not something that can easily be retrofitted to an existing rendering engine design. That’s not to say that people haven’t been thinking about it:
Fast and Parallel Webpage Layout by Meyerovich & Bodik’ introduced the concepts of multithreaded layout and parallel CSS. Their prototype browser demonstrated the performance improvements of parallelism.
Adrenaline was a project where an edge server split the web page down into multiple mini pages before sending the results to the Adrenaline browser to render them in parallel.
Zoomm, Qualcomm Research’s parallel browser project, focused upon using additional processor cores to prescan the HTML to preload network resources, and process them outside the critical path of page loading. A new approach to CSS matching and styling was also exploited to gain additional speed.
Servo is a parallel browser project from Mozilla which aims to achieve better parallelism, security, and performance. Servo’s architecture includes a multithreaded layout engine and GPU based OpenGL rendering.
Flow from Ekioh is a parallel browser primarily aimed at the consumer electronics and embedded systems markets. Flow combines a multithreaded layout engine with OpenGL ES based GPU rendering for improved animation performance and lower memory usage.
Whilst some of these activities have fallen by the wayside, Servo and Flow are actively being developed and enhanced. Although unrelated, they share many similar design philosophies and offer the potential for significant performance benefits.
Will a new rendering engine maintain the wider appeal of HTML?
It’s fair to say that Flow is unlikely to challenge Chrome’s top spot in the desktop market, but in the more minority use cases, its layout and rendering performance are key to improving the user experience on consumer electronics. By addressing the performance problems of HTML on embedded silicon, Flow helps to ensure that the flexibility of HTML remains a viable option beyond the open web.
If you’d like to automatically receive our posts by email please join our mailing list.
