Re: [w3ctag/design-reviews] Web page settings to save battery (#546)

> It's not clear to me that there's much value in an explicit opt-in from a site for throttling. Most sites won't adopt, so user agents which engage in throttling are going to do so regardless of whether or not the site opts in.

The value for an opt-in is for a site to indicate that it values battery savings over high framerate. Without an opt-in, the browser cant' know whether throttling of framerate would harm user experience more than it helped battery life.

You're also referring to a goal of the browser improving battery life of the device overall. You are correct that if only certain sites opt in, then relying on the opt-in will not improve device battery life for users that do not heavily use the opting-in sites. Nevertheless this feature still helps those users who *do* heavily rely on it. Video conferencing sites are often very heavily used, so in fact just optimizing those sites will substantially improve battery life for many users.

An approach that throttles the framerate for all sites, either via *user* opt-in or based on a device battery life signal, are good to consider but are different use cases.

> I don't understand the video conferensing use-cases. If I operate such a service and want to save battery etc, I would lower resolution and frame rate for instance to 15 fps instead of 30. I really don't want the browser to throttle me so that I loose frames which can result in a terrible user experience.

This doesn't work for CSS animations, which cannot control their own framerate. It's very common for video conferencing sites to have animations on top of the video that are implemented in HTML, for example to indicate who is speaking or whether a person is speaking. Even if the video drops to 15 or 30 FPS, the CSS animation is always at 60. Opting into reduced framerate allows the browser to match the video and CSS animation framerates when both are happening.

There are also use cases where developers *do* want 60 FPS CSS animations on top of a video or offscreen canvas, for example for gaming. Therefore I think an opt-in is needed.

> But this is a global thing so it would affect all tasks. It feels like the postTask scheduling proposal might fit this use-cases better.

Yes, but putting the thread on a "little core" would have a much greater impact on power efficiency, be simpler to implement for browsers and developers, and have more predictable performance.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/546#issuecomment-697618298