So the garbage collections appear to be from different processes. I'm running the app on a 1.5 device. So hopefully on 1.6+, my foreground process will get more processing time.
I have the choice of either using SurfaceView with Canvas.draw() methods, or just use an opengl renderer. I'm guessing the opengl renderer method would still beat out in fps, but will it also use less battery power? For example, if I have two more or less equivalent draw loops, should an implementation using only opengl be more battery efficient? Thanks On Dec 28, 1:42 pm, Timothy F <[email protected]> wrote: > You can tell very easily in LogCat whether the GCs belong to your task > or another task. If they belong to another task, then at least you > can take consolation that Android 1.6 (I think?) gives less CPU to > background tasks. If they belong to your own task, then you should > run the DDMS tool (not the DDMS perspective) to see what objects are > being allocated and from what sites. Then, presuming the object > allocations are inherent to the Android draw loop, you may want to > consider using OpenGL ES: we have been able to code a number of > applications that don't create any new objects within the main render > loop. > > On Dec 28, 12:36 pm, Dan Sherman <[email protected]> wrote: > > > > > No matter what you'll see GC being called, there's no way around it (that > > I'm aware of). > > > There are background threads that are doing all sorts of things, which very > > well might be getting GC'd. Theres also a lot of things you can't > > reasonably avoid, like allocations from Iterators and such... > > > On Mon, Dec 28, 2009 at 12:32 PM, Mark Wyszomierski <[email protected]>wrote: > > > > Hi, > > > > I'm drawing a rect to a surfaceview. Nothing special, just a test like > > > this, in the surfaceview-extended class: > > > > private int mPosX = 0; > > > private Paint mPaint = new Paint(); > > > > �...@override > > > public void onDraw(Canvas canvas) { > > > canvas.drawRect(mPosX-20, 50, mPosX+20, 70, mPaint); > > > > mPosX += mSignX; > > > if (mPosX > 320) { > > > mSignX = -1; > > > } > > > else if (mPosX < 0) { > > > mSignX = 1; > > > } > > > } > > > > the rect just bounces around the screen. I'm watching DDMS, I still > > > see the garbage collector being called, even with this simple draw > > > loop. There is no other application code being executed. > > > > I'm wondering if it's realistic to expect the gc to not be called at > > > all if we take care to not allocate any objects during our draw loops. > > > I'm trying to extend this example to do some smooth animations, but > > > every once in awhile the gc is called and you can see the drawing > > > stutter. Although none of my application code is allocating any new > > > objects, I don't know what the underlying API is doing inside > > > surfaceview etc, and I doubt we can control that. > > > > Just wondering if this is not possible, I'd prefer to abandon this > > > game idea up-front if we can't guarantee smooth animations, > > > > Thanks > > > > -- > > > 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]<android-developers%2Bunsubs > > > [email protected]> > > > For more options, visit this group at > > >http://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
