Something to be aware of -- if you are running on a Tegra 2 class device like the Xoom, you will almost certainly need hardware accelerated drawing for any kind of decent performance. This is due to a combination of the screen having many more pixels than most existing phones, and the Tegra 2 CPU lacking support for the NEON instruction set (which Android's software drawing code can use to improve its rendering speed and is available on most ARM CPUs Android had previously run on).
Now, you could try implementing your drawing code with Canvas so it can be accelerated by Android 3.0. This will require getting your hands on a real Xoom or other upcoming tablet hardware to test on. It also probably still won't give you as good of performance as using OpenGL ES directly, though it may be a lot easier to implement for 2d stuff. (Some background -- the number of pixels on the screens of the devices Android runs on has generally been growing significantly faster than the CPU and bus speeds. This has made the limitations of software rendering increasingly noticeable. The Tegra 2 tablets are basically the point where this came to a head, and required that the 2d drawing API be hardware accelerated in order to get acceptable performance.) On Sun, Mar 27, 2011 at 4:09 AM, Nicholas Johnson <metthejohn...@gmail.com>wrote: > Bob, > > I recently released a game (actually just this week, called "Prism" or > "Prism Light" by Shadowpuppets), which doesn't use OpenGL at all. I just > draw onto the canvas from my overrided onDraw method, and then invalidate > only the part of the view which contains animation. I have determined that > the drawing portion is the bottleneck for me (i.e. all the "physics" > calculations and the rest of the game engine have no effect on the > framerate). For your reference, I have an original Motorola Droid and I > generally get around 60 frames per second of animation. During beta testing, > other users with more advanced phones got upwards of 100 frames per second > (I actually had to put a frame rate limiter in my game to keep it at 60 fps > max). > > *However!* This is my experience only and is unique to my game. If you > download and play the free version, then you'll notice that my game board > only takes up about 2/3 of the screen (and that is the *only* part of the > screen which can be animated in my game). Furthermore, the performance > increased drastically when I clipped the regions of the screen which didn't > contain any animation. For example, my worst possible case scenario was > needing to animation something in the top left corner and the bottom right > corner at the same time. This causes the entire view to be redrawn and > results in my worst frame rate scenario. In this case, the frame rate > dropped to around 40 or 45 fps. At any other time, when the clipped region > didn't take up the entire game board the frame rate increased upwards and > past 60 fps (of note: even though the region was clipped, I still drew all > the animations to the canvas, even if they were totally outside the clipped > region. This didn't seem to affect the increased frame rate -- that is, it > mostly depended on what actually gets pushed out to the screen buffers). So, > it varies, but overall I got acceptable performance. > > Also, depending on what devices you target, there are other options. For > instance, if you're just targeting Honeycomb then you can enable hardware > acceleration for your view with only the addition of 1 line of Java code > (see the Developer's Guide recent Blog on the subject). > > I haven't tried using OpenGL for my game, because overall I didn't need it. > I was prepared to try, but I found that drawing my 2D animated game onto a > view's canvas was sufficient for my purposes. I hope that this gives you the > perspective you were looking for. > > Nick > > -- > 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 > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
