Re: [whatwg] Proposal: Wake Lock API

On Thu, Aug 14, 2014 at 9:55 AM, Jesper Kristensen
<mail@jesperkristensen.dk> wrote:
> 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.

The main use case for system locks in my mind is for applications that
need to do some short but important processing. For example a camera
app wanting to do some HDR processing of an image before saving it to
disk. It seems like it would be very annoying if a notification was
shown any time the user took a picture.

I still think it's a very interesting idea though.

/ Jonas

> 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 21:03:08 UTC