Subtract the window's area from the unoccluded screen rectangle. Ignoring these kinds of windows may cause some occluded windows to be considered visible (false negatives) but importantly it won’t lead to treating visible windows as occluded (false positives). Iterate over the open windows on the desktop from front to back, ignoring invisible windows, transparent windows, floating windows (windows with style WS_EX_TOOLBAR), cloaked windows, windows on other virtual desktops, non-rectangular windows, etc. Compute the virtual screen rectangle, which combines the display monitors. Mark Chrome windows on a different virtual desktop as occluded. Ignore minimized windows, since they’re not visible. So, we compute occlusion on a separate thread, as follows: We also don’t want to block the UI thread while doing the occlusion calculation, because that could reduce the responsiveness of Chrome and degrade the user experience. This needs to be done with great care, because if we decide that a window is occluded when in fact it is visible to the user, then the area where the user expects to see web contents will be white. In practice, however, there are lots of complications, such as multi-monitor setups, virtual desktops, non-opaque windows, and even cloaked windows(!). (The location information is discarded immediately after it is used in the occlusion calculation.)Ĭalculating Occlusion In theory, figuring out which windows are occluded is fairly simple. 
We called this project Native Window Occlusion, because we had to know about the location of native, non-Chrome windows on the user’s screen.
So, around three years ago, we started working on a project to track the occlusion state of each Chrome window in real time, and lower the priority of tabs in occluded windows. If these occluded windows were treated like background tabs, our hypothesis was that we would see significant performance benefits. Through experiments, we found that nearly 20% of Chrome windows are completely covered by other windows, i.e., occluded. However, the logic was limited to tabs that weren't focused in their window, or windows that were minimized or otherwise moved offscreen. This reduces CPU, GPU and memory usage, which leaves more memory, CPU and GPU for foreground tabs that the user actually sees. For example, JavaScript is throttled in background tabs, and these tabs don’t render web content. BackgroundFor several years, to improve the user experience, Chrome has lowered the priority of background tabs.
0 kommentar(er)
