Re: [battery] Alternative design proposal (was: addEventListener side effects, ordering & boundary crossing ...)

On 9/15/2011 12:53 AM, Anssi Kostiainen wrote:
> Hi,
>
> On 14.9.2011, at 17.20, ext Josh Soref wrote:
>
>> Anssi: of note, battery percentages can vary wildly if someone is amusing and swaps battery sources, a system can easily go from 100% charged to 50% charged (insert an empty battery), or from 99% charged to 33% charged (insert an empty high capacity battery). For more fun, it could go from 40% charged (kinda low), to 15% charged (insert an empty high capacity battery while trying to give more power to the system). In each of these cases, the actual amount of time remaining for the system hasn't changed, but you're going to cause any application listening to a percentage to panic.
> This use case justifies the existence of battery{low|critical|ok} events.


We could scale our use of Web Workers, and more aggressively flush our 
memory to localStorage/disk, without going into a panic
or otherwise intruding on user experience.

I've asked for a similar API for memory events; the iPhone is especially 
sensitive to low memory issues. That proposal was turned down on similar 
grounds, of being too unstable.

We don't need a perfect solution, just hints. We can use timers, release 
memory blocks, and take different code paths based on system hints.
It's something we do anyway.

This is something I expect will be useful for long running web apps, for 
compute/memory intensive/high resolution input.

For documents, and the other 99% of work that web authors do, it may not 
be relevant.

-Charles

Received on Thursday, 15 September 2011 16:34:33 UTC