- From: Marcos Caceres <w3c@marcosc.com>
- Date: Thu, 17 Jul 2014 10:17:34 -0400
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: whatwg@lists.whatwg.org
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.
Received on Thursday, 17 July 2014 14:18:06 UTC