If you are implementing a game or any other application that has complex animations, a SurfaceView will eek out more frames per second. That is, your class that extends View and implements the custom drawing could extend SurfaceView instead of View to have minimum overhead aside from the drawing.
My suggestion would be to start with a normal view (calling invalidate () from within the onDraw() method to keep the animation going), profile the drawing time, and only then bother switching to a surface view if the frames per second is too low (60 frames per second or greater is perfect, 30 is the minimum to not start looking choppy). an example of using a normal view for a game: http://code.google.com/p/apps-for-android/source/browse/trunk/DivideAndConquer/src/com/google/android/divideandconquer/DivideAndConquerView.java?r=40 to see an example of a SurfaceView in action, see LunarView in the lunar lander app in the sample code included with the SDK. then again, if you know you want to maximize the frames per second from the outset, you might just start with a SurfaceView. Karl On Dec 27 2008, 10:54 am, "Satya Komatineni" <satya.komatin...@gmail.com> wrote: > What doesSurfaceViewabstraction stand for? > > The documentation suggests thatSurfaceViewallows a secondary thread > to draw on it. > > When would one specialize View vsSurfaceView? > > Thanks for your help > Satya --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
