Hey don't knock java... if background processes weren't allowed, then this wouldn't be an issue.
But that's one of the good things about Android isn't it... LOL. Even a proper desktop or laptop computer struggles when a big background process (anti virus etc.) hits and sucks resources (network, memory, disk etc.), away from the foreground processes. It's difficult to expect a a much less capable device to fare any better. The real problem is support and not getting an application returned in the first 24 hours... imagine the user who has added "big fat background process" as an application on their phone. I'd imagine the developer of "big fat background process" doesn't add a disclaimer "this application may affect the quality and performance of other applications". How is the user to know that when your application is exhibiting signs of stutter or poor performance/frame rate (assuming it is coded right) that the issue is the background process. Maybe Google needs to add a permission to suspend/throttle background processing and the API needs to have a way to let the application suspend background processing in sections of their own code. For example a game might allow background processing on loading screens or end of level screens, but not in time critical sections of code. Just a thought. On Mar 26, 4:52 pm, Sundog <[email protected]> wrote: > So the EULA for Java needs to be extended: > > "You acknowledge that Software is not designed, licensed or intended > for use in the design, construction, operation or maintenance of any > nuclear facility or side-scrolling games." > > This is why I've always avoided Java until now. If you can't write > realtime code what good is it, especially for critically important > things like nuclear plants and games? ;) > > On Mar 26, 7:23 am, Incognito <[email protected]> wrote: > > > You will have the same problem in a computer if too many apps are running. > > The solution in a computer is to uninstall and dump those programs that hug > > too much memory. Same thing will happen in android. Those background > > processes that cannot play nice will get a bad reputation and be > > uninstalled. People must write their background processes so that they > > consume as little resources as possible or face an early death. The game > > will only stutter if there is excessive gc. > > > On Mar 26, 2009, at 9:13 AM, Stoyan Damov <[email protected]> wrote: > > > I don't see how opengl helps with the fact that the game's code runs > > on the *same* processor, as the one, doing the GC. > > You can have all your drawing occur on the GPU, but the game will > > *still* stutter, if a background process triggers GC, because the very > > drawGameScene() call will be postponed because of the GC. > > > On Thu, Mar 26, 2009 at 1:54 PM, Incognito <[email protected]> wrote: > > > Did you try opengl? > > > On Mar 26, 2009, at 5:18 AM, "[email protected]" > > <[email protected]> wrote: > > > because I don't think Android can handle smooth scrolling. Tried > > myself with all sorts of views, surface views, always a horrible > > flicker even with 20 - 30fps. > > > Looking at the market its the same story. Most games don't attempt > > side scrolling and the ones that do end up with very jerky scrolling, > > e.g. deBlob $3.99 ported from iPhone. Alien Blood Bath is a similar > > story. > > > I'm starting to think this is a technical limitation.If it is, this > > could mean our games never compete with other mobile platforms and > > could limit Android's ability to compete in the market. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
