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. 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. On Apr 19, 7:59 pm, mike <enervat...@gmail.com> 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 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
