Re: [whatwg] Proposal: Wake Lock API

Jonas Sicking <jonas@sicking.cc> writes:

> 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.

So what would happen if I want my laptop to go to into low-power mode by
closing the lid? Would I have to close a lot of risky web pages first?

> 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.

Such a CPU lock function looks to me like they can be easily abused,
without users necessarily finding out why their battery is drained or
their handset is becoming warm – while having no recourse except for not
using the offending web page (but note that web pages deemed important
by users can get away with all kinds of abusive stuff, like displaying
advertising and therefore using up bandwith and battery).

> 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.

I believe this is something that can be entirely done by the device
already, for example using motion or proximity detection built in.

> 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.

“Do not lock the screen during a movie and some time afterwards” is
something that can be done by a user agent quite well. Flash videos
never got this right.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

Received on Thursday, 14 August 2014 13:34:07 UTC