 Hi, I'm Chris Harrelson, the Blink Rendering Lead for Chrome. I'm in charge of teams whose areas of expertise span from parsing HTML and DOM APIs to translating all of that into rendering concepts like display lists, composited layers, and arresterized textures that can integrate with your computer's multi-core CPU, accelerated GPU, and high-resolution touch screens. And if you don't know what a display list or layer is, that's OK. In this video, I'll give an introduction to those concepts. And if you want to learn even more, the RenderingNG blog posts explain it all. Over the past eight plus years, we've been hard at work on a complete next generation re-implementation and architectural upgrade of the entire rendering pipeline of Chrome that I call RenderingNG. NG stands for Next Generation. We embarked on this effort because feedback from developers told us very clearly that browser rendering implementations were not good enough for the demands of the user experiences developers need to build. So we set out to change that in Chrome. Fixing all of it was an enormously difficult and complex challenge, but also critically important. And I'm happy to announce that as of this year, the architectural upgrade is done. The RenderingNG architecture puts in place a rendering pipeline with clearly defined pipeline phases. It uses data structures that can easily be passed across threads and processes. It supports running all animations and scrolls off the main thread in all cases. And it has excellent security and performance isolation for tabs and iframes in order to get the best possible performance. There were three main areas in which Chrome in particular was not good enough, reliability, performance, and extensibility. Developers had many complaints about bugs and inconsistencies between browsers. They reported it was impossible to achieve 60 frame per second animations or load complex pages fast enough. And they wanted to explore user experiences beyond just the affordances built into the browser, but were struggling to achieve them. We set out to solve each of these areas in turn. Reliability has to come first. There's no way to add product features if it isn't rock solid to begin with. So we spent quite a long time fixing bugs and adding testing to the existing system before being ready to reimagine that system. For example, we fixed an enormous number of subtle bugs in the layout subsystem alone. As we described in the LayoutNG deep dive blog post, there were a few root causes of these bugs that had to do with the pre-rendering NG architecture not being up to the task. And we set up mechanisms to continuously monitor and improve quality over time, including bug and regression SLAs and benchmarks such as Compat 2021. Next up came performance. There we had the goal of enabling developers to easily utilize all of the powerful hardware in today's devices to their full potential. But there's also the goal of making the browser as efficient as possible, preserving battery life and providing a good user experience regardless of whether the device was on the high or low end of capabilities. Finally, we planned for extensibility. We want developers to be able to achieve the user experience they want, but in a way that takes advantage of the power of the browser for excellent performance, accessibility, and reuse of existing built-in features. To do so, we designed the architecture very carefully to provide extension points for developers in just the right places. Now, let's briefly go over the key projects that make up rendering NG. Composite After Paint is a project to disentangle compositing from style, layout, and paint so that we can increase throughput and use less memory without sacrificing performance. Composite After Paint also fundamentally improves our ability to achieve additional performance isolation of animations from JavaScript. Layout NG is a ground-up rewrite of all layout algorithms for greatly improved reliability and more predictable performance. Blink NG is a systematic cleanup and refactoring of the Blink rendering engine into cleanly and separated pipeline phases. This work proceeded continuously and completed this year. GPU acceleration everywhere is a long-term effort to roll out GPU rasterization, draw, and animation on all platforms all of the time. Threaded scrolling, animations, and decode is a long-term effort to move all scrolling, non-layout-inducing animations, and image decoding off the main thread. Viz is a centralized raster and draw process for Chrome that increases throughput, optimizes memory, and allows for optimal use of hardware capabilities. Threaded and accelerated canvas rendering is the project that put in place the architectural pieces that made off-screen canvas possible. And finally, Video NG is a long-term effort to provide efficient, reliable, and high-quality video playback on the web. Now I'd like to give a brief overview of how the rendering NG architecture works on the inside. The entire system is organized into a high-performance rendering pipeline with a number of stages, each of which performs a well-defined task. If you're a web developer, the inputs to the pipeline are familiar, DOM, style sheets, fonts, images, video. But the magic and the mystery of browsers is what exactly they do to turn all that into pixels. The pipeline starts with animation updates, then runs style, layout, pre-paint, scroll, paint, commit, layerization, raster, activation, aggregation, and finally draw. And along the way, the pipeline creates a number of intermediate data structures. I'll talk about those data structures in a bit, but first let me draw your attention to the colors of the pipeline stages that you can see here. Green, yellow, and orange. These colors have to do with which thread or CPU process is running these stages. Green is the main thread, yellow is the compositor thread, and orange is the Viz process. Because not only are there 12 stages and seven or more key data structures, the whole thing is highly parallelized. Rendering NG makes maximal use of multiple CPU processes and threads to achieve performance isolation, parallelism, and security sandboxing. Each distinct site is placed in its own render process. This means that different tabs and windows from different sites run in parallel and don't jank each other. It also means that cross-origin iframes such as ads within a site don't slow down the site and vice versa. Likewise, the browser UI is fully isolated from the performance of browser tabs, that you always be able to control the browser regardless of site performance. Finally, all graphics are centralized in a Viz process, which can integrate iframes, tabs, off-screen canvases, video, and the browser UI into an optimized GPU rendering system that takes full advantage of your computer's capability without loss of efficiency or security. Within each process, there are a number of CPU threads. This allows operations such as JavaScript, scrolling, and image decoding to all happen in parallel. And it's all optimized to maximize throughput, smoothness, and responsiveness of scrolling your page interactions and animations. And finally, there are well-defined components within each thread and process to access all of the web platform APIs, process input from touch devices, mice, and keyboards, and schedule work efficiently and fairly. The renderer main thread has the DOM APIs with which you may be familiar and also runs JavaScript. The render compositor thread runs animations, handles input, and composites and rasters content. Here is an example set of pages and iframes. Let's see how that example maps to the above concepts in practice. First, CPU processes and threads. As you can see, there are a lot of them. However, each one falls into the groups I mentioned earlier and following that pattern, the browser can scale well to many tabs and sites at once with good performance. Second, here is how the rendering pipeline flows through those components in order to update rendering on the page. In this example, a change to the DOM starts in the main thread via a page loading, JavaScript changing page state, or a built-in browser feature doing the same. The steps go from the main thread all the way to this and back multiple times in a complex, coordinated dance. But code structure is not all. There are several key data structures that underpin the entire architecture. These data structures are the key to defining clear inputs and outputs to the pipeline stages. They are also critical parts of being able to safely, correctly, and efficiently accelerate and make extensible any kind of UI developers might put on their site. HTML and CSS have a huge variety of ways to express visual designs and it's really important to be able to accelerate all of them, not just to select subset. Frame trees are a way to represent the hierarchy of pages and iframes for a browser tab. Without this data structure, security and performance isolation of cross-origin iframes would not be possible. In the flow chart shown here, you can see that there are a number of steps in merely resizing a webpage that have to be coordinated across multiple processes because there could be one or more cross-origin iframes embedded within a page and those iframes also need to be resized. The immutable fragment tree represents the output of layout but also the input to feature layouts. This data structure is the key to how layout and G massively improve the reliability of the layout pipeline phase. Property trees are at the center of a lot of things but in particular are the key data structure that makes it possible to clearly express the visual hierarchy of a webpage. This in turn makes it much easier to accelerate animations and rendering of all content. The example property trees shown here are for a relatively simple setup of a scroller with rounded corners containing an iframe plus a rotations transform and a blur filter. As you can see, the property trees are already somewhat complicated. It can get much more complicated on a real page with many moving parts but due to the clean and thorough design of property trees, the system scales easily to these cases without massive complications. Display lists and paint chunks are critical keys to being able to not just efficiently paint a webpage but also composite it onto the GPU in a maximally performant and efficient way. And last but not least, compositor frames are how the browser can coordinate drawing multiple kinds of content on the screen while still allowing them to be computed in parallel on different CPU processes and threads. So that is a whirlwind tour of rendering NG. But what now? We have all this technology. What kind of things is it unblock? What kind of new features can we build on the web with it? The first thing worth noting is that rendering NG greatly improves the performance of all websites. Their render, animate, process input and scale much better than before and all without developers having to do anything. In fact, the speedups have been coming at a regular clip for over eight years now behind the scenes. As I explained in a blog post recently as part of the Fast and the Curious series, the composite after paint feature alone improves scroll latency, responsiveness, peak rendering speed, GPU memory use, time spent rendering and battery life by significant factors. In addition, there are important new developer APIs that the community has desperately wanted for many years, but browsers were unable to implement. Rendering NG has made many of these APIs possible and in fact, we have already shipped some and more are on the way. Let's walk through some examples. Container queries, the number one feature request in the state of CSS survey for several years running is an API to let components be responsive to their embedding context, not just to the size of the viewport. Async rendering allows the browser to only render what you need on the screen without forcing the developer to virtualize content. Scroll linked animations add support for moving content in precise lockstep with the scroll gesture. Shared element transitions add animations during single page app and multi-page app navigations to make them much more seamless. And finally, Offscreen Canvas is the very first web API that allows a developer to run their own rendering code off the main thread. I'm excited to see what web developers will build on top of this technology. And again, if you're interested to learn more, please check out the whole blog post series, which has much more detail than I could fit into this short video. And watch for more blog posts to come on additional parts of rendering NG. Thanks for listening.