Probably out of context but this issue looks similar to the thread
shown below.
http://groups.google.com/group/android-developers/browse_thread/thread/220248cd27e281c6/96ec2dd63c6850ab?lnk=gst&q=AUDIO+STUTTERING#96ec2dd63c6850ab
Audio stuttering problems in android.When somthing cpu intensive is
r
Mike, I'm with Robert on this one. Not because you're wrong -- you're
not.
But because most users don't really want to think about this stuff.
I think that if they were asked if they want to enter game mode -- a
single choice -- and they can either accept or decline, then users
will either accept
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 yo
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
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 CP
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 sayin
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 sch
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.
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 f
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 fa
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'll repeat my question from the bug:
So if this defect is not a defect, what are the plans to make it so
that our games
don't have periods of lag caused by greedy background processes that
we can't control?
As it stands, gaming on Android is a laggy experience and this is one
of the issues.
On A
Perhaps the issue is simply more fundamentally difficult than
scheduling can fix and an exclusive mode (for games and other real-
time apps where users don't care about having their RSS feed up to
date, etc) is in order?
On Apr 19, 5:32 pm, Mark Murphy wrote:
> We were told that, as of Android 1.
13 matches
Mail list logo
