Re: [whatwg] Proposal: Wake Lock API

Hi

Would it make sense to tie the system lock to a notification?

For example:

new Notification("Processing...", {tag: "abc", progressBar: 0.8, 
wakeLock: "system"});

There are many myths and rumors about how to conserve battery on mobile 
devices. A small improvement could be to require apps to show some kind 
of UI whenever they are allowed to consume resources in the background.

-
Jesper Kristensen

Den 14-08-2014 kl. 03:00 skrev Jonas Sicking:
> On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>> On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
>>
>>> On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
>>>>
>>>> I don't have a strong opinion. My concern was mostly about developers
>>>> having to watch for a whole bunch of different interaction queues (touch
>>>> events, mouse events, focus events, orientation-change events, etc.) in
>>>> order to release the lock at the right time.
>>>
>>>
>>> Do you have specific UC? The basic UC I have in mind (reading a book,
>>> watching a video, playing a game) would not use a timeout.
>>
>>
>> Yes, Google Play Books will wait five minutes from the last interaction to turn off the screen. This is nice if you fall a sleep while reading and long enough for a user to read a page without having the screen dim.
>>
>> See:
>> http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books
>>
>> I was trying to model that problem with the API.
>>
>>>> Question remains if there are other kinds of locks that we might need.
>>>> For example, Firefox OS has "wifi" as a lock type. I'm assuming that
>>>> their model keeps the "cpu" on, but the device can still shut down the
>>>> radios on a device. In the proposal, we lump "wifi" and "cpu" into
>>>> "system".
>>>
>>> Why not breaking these in different sub-systems? I can definitely
>>> imagine my phone having the CPU kept at 100% while the screen is off if
>>> it requires to do a heavy computation. Forcing the screen to stay on
>>> while doing that would be a waste of battery.
>>
>> Sorry, I was trying to say exactly what you said above. No need to keep the screen on when using "system", obviously.
>>
>> Ideally, we could do something like:
>>
>> "display" = keep display on + system/cpu + network
>> "network" (wifi/cell) = system/cpu + network (screen off)
>> "system" = just cpu, turn off screen and radio.
>>
>> Hopefully, something like that means you don't need to pick an choose amongst numerous options.
>
> I think the locks are fairly orthogonal.
>
> Holding the "display" lock just prevents the normal "turn off device
> because user hasn't interacted with it for X minutes" timer from
> firing. I.e. while the display lock is held, the screen won't
> automatically time out and put the device to sleep.
>
> However if the user presses the "power" button the screen would still
> turn off and the device would still go to sleep.
>
> Holding the "system" lock however wouldn't prevent the screen from
> turning off. But it would prevent the CPU from going to sleep even if
> the screen times out or if the user presses the power button.
>
> Holding both "display" and "system" means that the screen won't time
> out. If the user presses the power button the screen would turn off
> but the CPU would still not be put to sleep.
>
> So I think it makes sense to expose an array of which locks the page
> holds since all combinations of the "system" and "display" locks yield
> different behavior.
>
> I am however more worried about that only having a request() and a
> release() function means that pages that contain multiple independent
> subsystems will have to make sure that they don't stomp on each
> other's locks. Simply counting request() calls vs. release() calls
> helps, but doesn't fully solve the problem. It's very easy to
> accidentally call release too many times, in response to some UI
> action for example.
>
> An alternative design would be something like
>
> x = new WakeLock("display");
> x.request();
> x.release();
>
> Extra calls of either request() or release() are ignored, but pages
> can create any number of WakeLocks of the same type.
>
>
> Regarding timeouts, the use case that I've come across many times is
> pages that contain a lot of text, or some form of puzzle. In those
> cases you don't want to completely disable the screen timeout. But you
> might want to set it to some larger large value, say 15 minutes.
>
> It's somewhat hard to work around the lack of a timeout. What you
> could do is to release the lock after 15 minutes, but then that means
> that the normal screen timer kicks in, which adds an unknown number of
> minutes of the screen being on.
>
> If you instead were able to create a "display" lock with a 15 minute
> timeout, the platform could use the longest value of 15 minutes and
> the platform screen timeout.
>
> And note that you in normal use cases *do* want the normal screen
> timeout to kick in when a "display" lock is released. I've seen the
> lack of this many times and it's really annoying. What happens is that
> after you're done watching a 30 minute movie, the application releases
> the lock and the screen immediately shuts off. Attempting to work
> around this by holding the lock for a few minutes past the movie ends
> means that the application has to guess how long timeout the user has
> configured his device to.
>
> I don't however know of any use cases for having a timeout for
> "system" locks. So I propose they are not supported there.
>
> I haven't thought about "network" locks enough to know if timeouts
> makes sense there (or if network locks in general are needed).
>
> / Jonas
>

Received on Thursday, 14 August 2014 16:55:36 UTC