On 04/19/2010 06:16 PM, Robert Green wrote:
Mike,
If I implemented what you are proposing where the game "Backs off" as
other processes want CPU, the game would choke itself down to 10FPS
while your email is being retrieved. Wanna know what kind of user
feedback that would create? I'll tell you:
1 star - Game sucks and lags hard. Don't get it.
I don't think that's the experience people want. People keep asking
for "real" games on the platform but "real" games are games with
better graphics, better AI, more physics, run faster and smoother,
etc... That means even more CPU and GPU. Those games can't have
2000ms periods of time with half CPU like what we get right now with
sync on. Users don't know why the game sucks for those 2 seconds.
They almost always assume it's the game, not the platform and not the
mail app.
Well, first let's try to keep all of the different aspects separate.
If Mark's previous mail is correct that there really is a scheduling
mess, then obviously that needs to be resolved not just for games
but for everything. Maybe that's the biggest problem, maybe there's
more.
BTW - I'm generally GPU-bound on these phones anyhow. I hardly use
1-2 milliseconds of CPU on the Droid or N1 and you can still see the
choppiness during sync. That says something is WRONG in my book and
it's not my max 2ms updates.
What I'm seeing here doesn't seem to add up. The mail app
(or IM, or baby cam alerter...) is most likely IO bound, and
secondarily CPU bound (if at all). It's certainly not GPU bound.
So obviously something is in contention if that's what you're
seeing.
But what? Until this is really categorized, it's rather premature
to call for a "give me everything, but..." kind of mode, right? Because
maybe the problem is just network IO and your app contenting for
memory bandwidth. Or something else that wouldn't help even if you
did have your mode.
The right thing to do here is really find out what's really going on
under the hood. That's likely to be extremely painful and time consuming,
but its ultimately better to find the problem areas and potentially file
bug reports than imagine a mode that isn't likely to be forthcoming
because of its own law of unintended consequences.
Mike
On Apr 19, 7:59 pm, mike<[email protected]> wrote:
On 04/19/2010 05:43 PM, Mark Murphy wrote:
Robert Green wrote:
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.
That's what the background process scheduling class was supposed to do,
or so I thought
Well, until you have a game or some other kind of cpu sink that's
right on the hairy edge that does an epic fail when the couple of
expected cpu ticks don't materialize.
Another way to help skin the cat is to provide frameworks for
intelligent background processing. Think of it as providing an
iPhone-style multi-tasking layer. Apps written to use those can be
"guaranteed" (-ish) to behave well. Apps that ignore the frameworks and
roll their own background processing can cause problems, and sufficient
"blame APIs" can help users identify the problematic stuff and get rid
of the apps, just as they get rid of apps that consume too much storage
or use too much battery.
Or maybe we're just thinking about this the wrong way. Games, etc
want to fill to available capacity no matter what the capacity is. There
is *no* well behaved background task that will satisfy them. Which is
understandable because what game/etc wants to cater to the least
common denominator? It won't happen.
What might be better is give the game/etc the ability to predict its
own degradation so that it can back off its refresh rate, etc. I'll bet
that this is a more productive route. Sort of a continuous CPU autosizing
loop. Which also has the nice property that it then autoscales to different
CPU speeds on different phones.
Mike
That won't help where the OS itself is the one chewing up the CPU
cycles, of course.
--
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
