In a new blog post for its series called The Fast and the Curious, Chrome Developer David Bienvenu details some of the improvements Google has made to its Chrome browser recently. This includes a deep dive into what the company calls Native Window Occlusion.
The blog post explains the work Google has done to reduce resource consumption by non-visible tabs and windows in Chrome, which it says has allowed Chrome to boast up to a 25.8 percent faster start up speed and to experience 4.5 percent fewer crashes. It also notes the company has been working for years on methods to better understand how to ascertain which Chrome windows and tabs are visible to the user, so it can allocate the system’s resources appropriately.
Naturally, tabs that are not in focus, known as “background tabs,” have reduced priority for CPU and GPU resources, but what about occluded windows — windows that are open, but completely or partially covered by other windows? Bienvenu writes that in studying this issue, Google learned that, “20% of Chrome windows are completely covered by other windows, i.e., occluded. If these occluded windows were treated like background tabs, our hypothesis was that we would see significant performance benefits.”
Thus began the Native Window Occlusion project, which would allow Google to understand the occlusion state of any open Chrome window. However, to figure this out, they had to know the location of non-Chrome windows too, which isn’t information that Windows OS readily provides. This gets even trickier when factors such as multi-monitor setups and virtual desktops are taken into consideration. To figure it out it created the “occlusion calculation,” which runs in a separate thread from the UI by first calculating the total visible area to the user, then subtracting all Chrome Windows from the visible area in a virtual desktop as “occluded.” It then examines each open window, from front to back, subtracting any open window from the total, and if its’ a Chrome window, it checks to see if its area overlaps with the un-occluded area. If it didn’t, that means the Chrome window is completely covered by previous windows, so it is occluded. The software keeps running the calculation until all Chrome windows are marked as occluded, meaning what is left must be visible to the user. With this information, a task is posted to the scheduler to update the windows’ visibility.
This diagram shows the sequence of events for the occlusion calculation, starting with the green cylinder. (Image: Google)
Where it gets interesting is the next step, which asks the question, “How often do we want to run this calculation?” As the author notes, running it continually would degrade performance, so they have to be selective. Thankfully, Windows allows apps to track events such as moving or resizing open windows, so Chrome is hooked into these notifications, so when you move or resize a Windows Chrome is alerted, and decides whether to do a new occlusion calculation. The blog notes this calculation runs on a 16ms timer, which corresponds to the interval between frames when displaying 60 frames per second(FPS).
Google rolled this change out to 100 percent of Chrome users in October 2020, and now that some time has passed the company is able to share the results of its “experiment,” which include:
- 8.5% to 25.8% faster startup
- 3.1% reduction in GPU memory usage
- 20.4% fewer renderer frames drawn overall
- 4.5% fewer clients experiencing renderer crashes
- 3.0% improvement in first input delay
- 6.7% improvement in first contentful paint and largest contentful paint (this is when you’re first able to see anything on screen, and when the page’s main content is visible)
Though none of this is breaking news, it’s interesting to read about what is happening behind the scenes, both with our browsers and with the Chrome team as well.
Now Read:
- New Leak May Reveal Google’s Long-Rumored Pixel Smartwatch
- Google Reportedly Killed Pixel Smartwatches in 2016 Because They Were Bad
- Google Launches YouTube Music on Apple Watch, Bypassing Wear OS
No comments:
Post a Comment