Mike, The whole issue is that the Sync and IM services are specifically what cause lag in games. If a user wants a smooth gaming experience, something's gotta go - or it's gotta be squashed way down so that it can't use much of the CPU.
I'm not saying I know what should stay and what should go. I don't. I just know what causes the issue and what would work to provide a good experience at the cost of flipping the phone effectively into airplane mode but with the ability to receive calls. On Apr 19, 7:07 pm, mike <[email protected]> wrote: > On 04/19/2010 04:56 PM, Robert Green wrote: > > > Bob, > > > The idea is that an exclusive mode would cater to apps that are never > > idle. Games are never idle. They constantly update and draw. There > > are other apps that work that way as well and having a more guaranteed > > consistent amount of CPU available for those simulations would > > probably be very favorable with consumers. I know I'd personally say > > "Yes" if a game prompted me to go into an optional game mode during > > the duration of play. If you're playing a game, you don't need > > background tasks running. All you would need is to receive a phone > > call. It is still a phone, after all. :) > > I get off the bus right here. At the point that you aren't willing > to say that it's not a phone while you're playing a game or whatever > this mode is, you're setting yourself up for failure. Why not an IM > from your boss wondering if you're working or playing game? What > about that alert that comes in from the baby cam that says that > the loinfruit is unhappy? > > The problem here is that you are presuming to know users' prioritiztion > of alerting, etc, based solely on tradition. That is bound to fail and > fail and fail as the generations who think of it as being "a phone afterall" > dwindle and eventually die out. It isn't a phone. It's a general purpose > computer with some telephony functions on it. > > So if there is going to be some mode that allows you to drown out > *every* other bit of background/alerting that's one thing. But if you're > going to start making exceptions -- which I think you must -- you've > opened up a much larger problem. > > Mike > > > > > > > If the user is expecting an > > email/text/other notification, they could opt not to go into game mode > > and the game will have its normal bits of choppiness. It really could > > be as simple as that. > > > After the exclusive mode is exited, paused services are resumed and > > all is happy on the device. > > > On Apr 19, 6:28 pm, Bob Kerns<[email protected]> wrote: > > >> Well, after looking at your code, my suggestion for advice would be: > > >> "Do no evil!" :=) > > >> When I implemented something like this on Symbolics Lisp Machines back > >> in the 1980's, I made the scheduling boost for UI actions be for a > >> limited period of time. Perhaps something like that is going on here? > > >> I did this, because I found that there would occasionally be some bit > >> of code or other that would do something in a UI thread (typically the > >> mouse-handling thread) that would consume however much CPU was > >> available, while waiting for the INTERESTING things to do to be > >> computed by another thread. And an unlimited priority boost in the UI > >> could tend to make the UI very difficult to debug, as well. > > >> So I had a macro that could be wrapped around various components of UI > >> code, that would boost the priority of the UI thread. It would boost > >> it for a maximum period of time, after which it would fall back to > >> normal. > > >> It would ALSO boost it for a *minimum* period of time. The idea being > >> that if you'd just done user interaction, then perhaps completing the > >> work implied by that interaction would also be of interest to the > >> user. The equivalent here would be to boost priority for any incoming > >> events on the main thread, up through some number of scheduler quanta. > > >> This all worked very well, but wasn't a panacea. The real fix was > >> usually to write the application better. > > >> Another factor to figure in here is scheduling quanta. When the > >> foreground "breaths", it allows the background to run. There will > >> always be a minimum amount of time the scheduler will allocate to run > >> anything it does decide to run. Otherwise, you'd waste too much time > >> switching back and forth! > > >> Anyway, I do agree with Robert Green that giving the scheduler > >> explicit information to aid it in policy decisions would be a good > >> thing. You still have to consider how to handle 'exclusive mode" -- do > >> you shut out non-foreground tasks entirely, even when the foreground > >> is idle? Because you may then be blocking the foreground for a > >> scheduling quantum? > > >> On Apr 19, 3:32 pm, Mark Murphy<[email protected]> wrote: > > >>> We were told that, as of Android 1.6, background processes were put in a > >>> Linux process scheduling class that limited how much CPU they would use. > >>> A few weeks ago, I ran a benchmark test that seemed to validate this > >>> claim. > > >>> I have run more tests, and I am no longer confident in my earlier > >>> conclusion. I can get a background process to significantly impact the > >>> foreground process, more than would seem to be possible if the > >>> background process was, indeed, CPU-limited. > > >>> Details, including sample code, can be found in the issue I opened that > >>> was promptly closed: > > >>>http://code.google.com/p/android/issues/detail?id=7844 > > >>> Clearly, the failed issue was my fault, for not running around screaming > >>> about bugs in Android and not jumping to conclusions. > > >>> Anyway, if anyone else has any ideas on how we can prove whether > >>> background processes are CPU-limited -- and if so, how come that's not > >>> helping much -- please respond to this thread or shoot me an email > >>> off-list if you prefer. > > >>> And, I apologize to anyone who took my prior advice regarding this CPU > >>> utilization, as it looks like I screwed up big-time on that analysis. > > >>> -- > >>> Mark Murphy (a Commons > >>> Guy)http://commonsware.com|http://twitter.com/commonsguy > > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups "Android Developers" group. > >>> To post to this group, send email to [email protected] > >>> To unsubscribe from this group, send email to > >>> [email protected] > >>> For more options, visit this group > >>> athttp://groups.google.com/group/android-developers?hl=en > > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Android Developers" group. > >> To post to this group, send email to [email protected] > >> To unsubscribe from this group, send email to > >> [email protected] > >> For more options, visit this group > >> athttp://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group > athttp://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
