Intent to Ship: Rendering pipeline throttling

[Sami Kyostila]

Contact emails

skyo...@chromium.org, oj...@chromium.org

Summary

We want to stop running Blink’s rendering pipeline (i.e., style, layout, animation and painting updates) for iframes which are outside the browser’s viewport. This can reduce power usage significantly and improve scrolling responsiveness, especially on pages with heavy ads and analytics scripts. A few team members have been using this on a regular basis with noticeable benefits and without issues.

Intent-to-implement thread

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_SRHebxivJs

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://jsfiddle.net/1mny39p9/1/embedded/

Specification

The web processing model specification has been updated to allow this type of intervention.

Interoperability and Compatibility Risk

To minimize the compatibility risk with existing content, we are only planning to throttle requestAnimationFrame callbacks for documents in cross origin frames. Because cross origin frames can't synchronously interact with the outside world, there isn't a direct way to observe the exact timing of animation updates in the embedded document.

Other browsers:

• Mozilla has shipped a similar intervention in Firefox 40. The bug mentions some issues with same-origin iframes. We reached out to see if they would tweak their intervention to only target cross origin iframes which would take care of this class of issues.

• Safari does a similar intervention in spirit, which is to throttle just requestAnimationFrame, but not the rest of the rendering pipeline (e.g. layout and paint).

Developer guidance

The main developer visible impact of this intervention is that requestAnimationFrame() callbacks will stop getting serviced while the document’s containing frame is outside the viewport. This is similar to what happens when the tab is backgrounded.

Note that we don’t provide developer control over this feature. We want to see how developers interact with it in the real world to understand what level of control is needed.

Reporting

There is no reporting when this intervention is applied, but in the near future developers can use an IntersectionObserver to find out when a frame’s visibility changes in a way to activate throttling.

Measuring

We intend to launch the intervention as a Finch experiment. Since there is currently no automated way to measure power usage on end user devices, we will use the following UMA statistics as proxies:

• Scheduling.Renderer.BeginMainFrameStartToCommitDuration for the cost of rendering pipeline execution (lower is better),

• Scheduling.Renderer.BeginMainFrameIntervalCritical -- Main thread update rate (both completed and aborted commits, lower is better),

• V8.GCIdleTimeAllottedInMS for the amount of idle time given to v8 for garbage collection (higher is better),

• Event.Latency.TouchToScrollUpdateSwapBegin for scroll latency (lower is better),

• Event.Latency.TouchToFirstScrollUpdateSwapBegin for the initial compositor scroll latency (lower is better).

OWP launch tracking bug

https://crbug.com/516640

Design doc

https://docs.google.com/document/d/1Dd4qi1b_iX-OCZpelvXxizjq6dDJ76XNtk37SZEoTYQ/

Entry on the feature dashboard

https://www.chromestatus.com/features/4514713492783104

[Dimitri Glazkov]

LGTM1.

:DG<

[Chris Harrelson]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

I think you may have copy-pasted or something... There is some contradiction, I think.

The summary says -

> We want to stop running Blink’s rendering pipeline (i.e., style, layout, animation and painting updates) for iframes which are outside the browser’s viewport

But the "Interoperability and Compatibility Risk" section says -

> To minimize the compatibility risk with existing content, we are only planning to throttle requestAnimationFrame callbacks for documents in cross origin frames.

And even goes on to say -

> Safari does a similar intervention in spirit, which is to throttle just requestAnimationFrame, but not the rest of the rendering pipeline (e.g. layout and paint).

(And more references thereafter)

So which is it?

And will element.offsetWidth return the correct value (since you are not stopping scripts) when used within those off-viewport iFrames?

☆PhistucK

[Sami Kyostila]

to 11. helmikuuta 2016 klo 17.36 PhistucK <phis...@gmail.com> kirjoitti:

I think you may have copy-pasted or something... There is some contradiction, I think.

The summary says -

> We want to stop running Blink’s rendering pipeline (i.e., style, layout, animation and painting updates) for iframes which are outside the browser’s viewport

But the "Interoperability and Compatibility Risk" section says -

> To minimize the compatibility risk with existing content, we are only planning to throttle requestAnimationFrame callbacks for documents in cross origin frames.

And even goes on to say -

> Safari does a similar intervention in spirit, which is to throttle just requestAnimationFrame, but not the rest of the rendering pipeline (e.g. layout and paint).

(And more references thereafter)

So which is it?

Sorry, you're right, that was my copy-paste gone wrong. The summary is accurate, but the interoperability part was meant to say that we're throttling the rendering pipeline -- not just rAF callbacks -- for cross origin frames.

And will element.offsetWidth return the correct value (since you are not stopping scripts) when used within those off-viewport iFrames?

Yes, that kind of on-demand style computation will still happen and result in the correct value.

 

☆PhistucK

- Sami

[Daniel Bratell]

On Thu, 11 Feb 2016 14:01:48 +0100, Sami Kyostila <skyo...@chromium.org> wrote:

Contact emails

skyo...@chromium.org, oj...@chromium.org

Summary

We want to stop running Blink’s rendering pipeline (i.e., style, layout, animation and painting updates) for iframes which are outside the browser’s viewport.

This sounds so much like the right thing to do! (non owner "seems awesome to me")

Scripts are still running I assume? And those will probably keep asking for coordinates and similar so style and layout might get some attention anyway.

Now if someone can give this poor guy a third blessing so that they can proceed. :-)

/Daniel

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Sami Kyostila]

ma 15. helmikuuta 2016 klo 19.31 Daniel Bratell <bra...@opera.com> kirjoitti:

On Thu, 11 Feb 2016 14:01:48 +0100, Sami Kyostila <skyo...@chromium.org> wrote:

Contact emails

skyo...@chromium.org, oj...@chromium.org

Summary

We want to stop running Blink’s rendering pipeline (i.e., style, layout, animation and painting updates) for iframes which are outside the browser’s viewport.

This sounds so much like the right thing to do! (non owner "seems awesome to me")

Scripts are still running I assume? And those will probably keep asking for coordinates and similar so style and layout might get some attention anyway.

That's right, we don't throttle timers, event handlers or anything like that. If the scripts end up requiring up-to-date style or layout information, it is computed on demand.

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google