On 04/19/2010 05:37 PM, Robert Green wrote:
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.
Yes, that's why a solution to this is not as straightforward
as just saying "phone alerts are exempt", because neither you
nor google have any clue if that actually matches users' *actual*
alert prioritization. And it's quite possible that trying to sort
that out lies madness.
I'm afraid that users really do want to have their cake and
eat it too. Fortuntately Moore's Law is on our side from going
completely crazy.
Mike
On Apr 19, 7:07 pm, mike<enervat...@gmail.com> 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<r...@acm.org> 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<mmur...@commonsware.com> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
