View Single Post
Old 10-31-2017, 03:12 AM   #12
mdp
Wizard
mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.
 
Posts: 1,481
Karma: 9010563
Join Date: Jul 2013
Device: none
Quote:
Originally Posted by mdp View Post
@Harry: I am not really sure it is as you are depicting it.
If you run an app in the background, it will take its share of battery as it is actually running, not when it is idle: in the case of Clipper, it is most probably triggered by the System only when "copying" occurs - it is not constantly checking. [...] The device never really sleeps... The system idles paused applications and activates processing only based on events.
Now that I see this post again: well, I only forgot about the CPU locks and screen locks, yes (only!). Under lock, the device responds to events, when it does, with dramatically reduced frequency. Thing is, applications should release locks on pause (or similar). The device should not sleep while you expect responsiveness. Here the "reader" model does not work. And extreme lock ("Rendered! Now freeze"), to bargain a little battery, is not necessarily a good idea - try that policy with text editing. There should be an option to toggle that (extreme lock placement, as often as possible, vs. relaxed lock placement, when the screen is turned off).

Last edited by mdp; 10-31-2017 at 03:16 AM.
mdp is offline   Reply With Quote