Intent to Extend Origin Trial: battery-savings meta tag

[Khushal Sagar]

Contact emails

khusha...@chromium.org, chri...@chromium.org

Explainer

https://github.com/chrishtr/battery-savings/blob/master/explainer.md

Summary

Adds a meta tag allowing a site to recommend measures for the user agent to apply in order to save battery life and optimize CPU usage. The mitigation targeted for this experiment is reducing the rendering frame rate.

An origin trial for this API started in M86 and is scheduled to end in M87. The most relevant use-case for this API has come from video conferencing apps, with the primary partner we've engaged with being Meet. The ongoing trial in Meet has shown reduction in overall CPU utilization (~3%), less instances of video quality reduction to mitigate high CPU usage (~7%) and improvements in user ratings for video calls (~1.5%) across all desktop platforms. We would like to extend the trial to M90 to better understand the UX use-cases involved and a need for a web standard.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/PQ9aDeWGUE0/m/qf07C9FDAgAJ

Goals for experimentation

The API proposal here is geared towards letting the browser decide when to use battery-savings mode and apply the mitigation to reduce rendering frame rate. But the feedback from the origin trial has been that the decision to reduce an animation's frame rate is dependent on the UI and it would be reasonable for the app itself to do it consistently, instead of relying on browser heuristics.

However, in some scenarios the app can set up its animations to run at a low rate but the browser doesn't synchronize them to the same frame internally. This causes the browser to redraw at a higher rate than the individual animations. It's not clear whether this can be fixed internally in the browser or whether we still need API hints to synchronize all animating content. For the continuation of the origin trial, we want to compare the impact of an explicit hint provided by this API against internal browser changes.

Experimental timeline

We'd like to extend the Origin Trial to run to M90.

Any risks when the experiment finishes?

As this feature is only available via Origin Trials and doesn't affect any existing state, we don't believe there will be any risks once the experiment concludes.

Reason this experiment is being extended

To gather additional feedback/data to assess the need and requirements for the new API.

Ongoing technical constraints
None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Currently implemented on desktop only but can be supported for Android as well.

Is this feature fully tested by web-platform-tests?

No None as yet

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5653874167775232

[Mike West]

LGTM.

It sounds like you're getting solid feedback from partners, and giving the OT a bit more time to bake sounds reasonable. If you can end up getting away with avoiding the API entirely (or in many cases) via internal browser changes, so much the better. Good luck experimenting!

-mike

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUx_aFZYQwju1G1q3Rde12in%2B8vS83Q294DNv6%3DXMrY0Vg%40mail.gmail.com.

[Arthur Sonzogni]

Nice results!
+1 to Mike. I am wondering if we couldn't get some kind of universal benefits if this wasn't gated behind an API.

This experiment is only about allow-reducing-frame-rate. In general, for the whole intent, we would be happy to see a section about your security & privacy considerations.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3De4a50D%2BCdVC480Yxsmd4_eB1Lwa6dPL5TvhcHLFxqExw%40mail.gmail.com.

[Khushal Sagar]

On Tue, Nov 17, 2020 at 9:05 AM Arthur Sonzogni <arthurs...@google.com> wrote:

Nice results!
+1 to Mike. I am wondering if we couldn't get some kind of universal benefits if this wasn't gated behind an API.

Interestingly, it isn't limited to the API. :) The reduced-frame-rate optimization has 2 parts to it, dynamically throttling animations and batching all animation updates to keep rendering costs low. We try to do the latter already if animations on the page are set up to render at a low rate. The logic is heuristic based and has shown gains but it's not perfect.

 

 

This experiment is only about allow-reducing-frame-rate. In general, for the whole intent, we would be happy to see a section about your security & privacy considerations.

There was some discussion about privacy/security considerations, only targeted towards reduced-frame-rate so far, here (sorry, internal link).