Making the web smoother with independent rendering - in RS3, though

Published by at

There's an interesting piece over at the Windows blog talking about the significant increases in rendering speed coming to Microsoft Edge and the EdgeHTML engine. Given that this is all common to Windows 10 Mobile, this should be of major relevance to many here, but there's a huge caveat - this is all for the Redstone 3 (RS3) branch of Windows 10 onwards, and it's very likely that no current mobile hardware will progress past the 'feature2' branch (with updates and fixes, but staying within the same branch).

From the blog post:

Independent rendering allows the browser to selectively offload graphics processing to an additional CPU thread, so they can be rendered with minimal impact to the user interface thread and the overall visible performance characteristics page, such as silk-smooth scrolling, responsive interactions, and fluid animations. This technique was pioneered in Internet Explorer 11, and is key to providing a fluid experience.

Today, we’re excited to share major improvements to the independent rendering pipeline in Microsoft Edge which will make pages significantly faster in EdgeHTML 16 and the Windows 10 Fall Creators Update.

Independent rendering is transformative to the user experience — but historically there have been a few elements that could disable it entirely when present on a page.

  • <select> control
  • <canvas> element
  • certain <svg> elements

Starting with EdgeHTML 16, we’ve enabled independent rendering on more sites by adding full support for the elements listed above. These investments greatly improve actual and perceived performance of a huge number of apps and sites, as these elements are very common on the web. You can preview these changes in recent builds via the Windows Insider Program – read on to learn more about the impact of these changes!

Visualizing independent rendering improvements

Independent rendering noticeably improves performance in several common scenarios: content processing, such as loading the page or adding significant portions of dynamically generated content; iterative operations or experiences with tight frame budgets, such as games, script-driven animations, and data visualizations; and scrolling while the main thread is processing script, where the rendering thread can continue displaying available content even if main thread is busy...

Figure 1. CPU activity sequence required to display a web page in EdgeHTML 15. Note that the rendering thread is available, but is not always used due to the presence of certain elements on the page.

Figure 1. CPU activity sequence required to display a web page in EdgeHTML 15. Note that the rendering thread is available, but is not always used due to the presence of certain elements on the page.

Now that EdgeHTML 16 supports independent rendering of these elements, rendering can happen independently of content processing:

Figure 2. CPU activity sequence required to display a web page in EdgeHTML 16.

Figure 2. CPU activity sequence required to display a web page in EdgeHTML 16.

By leveraging multiple CPU cores, parallelized rendering results in faster page load times across the sites you use daily while using a similar amount of total CPU time.

Good to see from the point of view of the Edge browser and UWP apps which use EdgeHTML being faster on tablet, hybrids, laptops and Xbox, though we'll - probably - need the next generation of Windows 10 mobile hardware (running Redstone 3 - Fall Creators Update - or beyond) for phone browsing to be similarly improved.

I'm pretty happy with Edge as it is on the current Windows 10 Mobile flagships, mind you - is it too slow or clunky for you? Any particular bogey sites?

Source / Credit: Windows Blog