- From: Jesper Kristensen <mail@jesperkristensen.dk>
- Date: Thu, 14 Aug 2014 18:55:11 +0200
- To: Jonas Sicking <jonas@sicking.cc>, Marcos Caceres <w3c@marcosc.com>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Mounir Lamouri <mounir@lamouri.fr>
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