Published using Google Docs
Throttling Blink's rendering pipeline for hidden content
Updated automatically every 5 minutes

PUBLIC

Throttling Blink’s rendering pipeline for hidden content

skyostil@

August 28th, 2015

Tracking bug: 487937

Patch: https://codereview.chromium.org/1364063007/

Introduction

Pages with many animated elements – often advertisements – can end up having a poor user experience or low power efficiency because animation and other work is performed for the entire page instead of just the visible parts. This document proposes an improvement where we limit the amount of computation we do for frames which are outside the visible viewport bounds.

Algorithm

The diagram above (adapted from Resize Observers) shows the main stages of Blink’s rendering pipeline plus a new stage for configuring per-frame throttling. Each of the stages processes the whole frame tree recursively. The proposal is to terminate the recursion at each stage if:

  1. the frame to be processed is outside the visible viewport bounds, and
  2. the frame to be processed is in a different security origin compared to the current frame.

In practice, this will stop all rendering pipeline related processing in each respective stage for cross-origin frames which are outside the viewport.

Cross-origin requirement

The visibility determination is only done for cross-origin frames to reduce the chances of breaking content which could synchronously observe the suspension of rAF callbacks and other side effects the pipeline in the affected frame. Cross-origin frames can only communicate asynchronously, so existing content must already deal with deferred responses.

Visibility determination

Every time a frame’s geometry changes, we recursively project its bounds all the way up to the root frame view. At each level the bounds are clipped to the intermediate frame’s viewport. If the bounds become empty at any point, this means the frame isn’t visible in the root viewport.

Note that we use exact visibility determination instead of relying on the compositor prepainting region. This is because the compositor currently uses an aggressively large (several kpixels) prepainting region, limiting the effectiveness of this optimization. As a future improvement a “Soon” visibility state could be added to reduce the chances of seeing stale content while scrolling.

Throttling update stage

The new throttling update stage ensures that throttling is enabled or disabled at controlled times. This is because the visibility of a frame could change at any point during the animate, rAF or layout stages, but it is not possible to start the pipeline for a frame in the middle without also going through all the preceding stages. Instead, the new visibility information is applied to throttling at the very end of the pipeline; if any frame became unthrottled because of this, we schedule another pipeline update to guarantee eventual consistency.

Forced layouts

Sometimes Blink needs to perform a forced layout (a.k.a. lifecycle update) to obtain consistent geometry information. This happens for example during hit tests. In these cases we need to run the style, layout and compositing update parts of the pipeline for every frame including throttled ones.

Future improvements

Open issues

Resources

Research