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. 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. Will a new rendering engine maintain the wider appeal of HTML? Although unrelated, they share many similar design philosophies and offer the potential for significant performance benefits. Whilst some of these activities have fallen by the wayside, Servo and Flow are actively being developed and enhanced. Flow combines a multithreaded layout engine with OpenGL ES based GPU rendering for improved animation performance and lower memory usage. Servo’s architecture includes a multithreaded layout engine and GPU based OpenGL rendering.įlow from Ekioh is a parallel browser primarily aimed at the consumer electronics and embedded systems markets. Servo is a parallel browser project from Mozilla which aims to achieve better parallelism, security, and performance. A new approach to CSS matching and styling was also exploited to gain additional speed. 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.
Their prototype browser demonstrated the performance improvements of parallelism.Īdrenaline 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. That’s not to say that people haven’t been thinking about it:įast and Parallel Webpage Layout by Meyerovich & Bodik’ introduced the concepts of multithreaded layout and parallel CSS. Multithreaded layout is not something that can easily be retrofitted to an existing rendering engine design. 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.ĭuring 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.
Unfortunately, for user interfaces, it is single page performance that matters and the restrictions of single threaded layout can impact the user experience.įor most people with fast computers or phones, layout speed on the open web is fast enough.
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. Today’s browsers now use a multi-process architecture where each page can be allocated its own process.
#Webkit vs blink full#
Being single threaded means that the rendering engine isn’t making full use of multi-core processors. 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. All three main browser engines are developing at a rapid pace, but some aspects have barely changed since they were first written.