My first reaction is that if you really want render speed then you need to be leveraging the GPU which is going to be most reliable with OpenGL (as I understanding it more recent versions of Android will actually hardware accelerate for you, but there are many variables that affect whether this works, not least of which is the Android version running on the user's device).
However, the requirement for "fast rendering" may be misleading. Render speeds will vary wildly from device to device regardless of what mechanism you use, and you don't have any control over this. Game development faces this issue perhaps more than most but the key thing is to effectively "synchronize and interpolate". This means two things: 1. Changes in pixel color on screen (any change in the screen image is effectively a pixel color change) need to be synchronized with changes in the objects they represent. That is, if there are several objects in the scene that are changing position it is important that all the changes for a single frame are done without it affecting what's rendered to screen until ALL changes are done. Failure to do this will often result in "tearing" of visuals or jittery movement. 2. If there is a separation between changes in "world coordinate" objects and "screen coordinate" objects (i.e. the actual objects and their on-screen representations) there can sometimes be a case where changes in world coordinates are out of sync with screen refreshes. This is common in games where the "game thread" is using a fixed time step to calculate changes in world coordinates but the screen refresh rate is variable. In these cases it's important to keep both coordinate spaces in sync and one way to do this is to interpolate the world coordinates where there is an uneven number of "steps" required to synchronize the amount of time that has passed between screen render operations. For example if the fixed time step is 16ms, but the last render took 24ms you need 1.5 steps to accomodate this. In a fixed time step environment there is no such thing as a "half a step" so you need to perform 2 full steps then "estimate" the position at 1.5 steps by interpolating back from 2 to 1.5. Wow.. that was probably way more complicated than it needed to be :/ On Sunday, March 31, 2013 6:59:44 AM UTC-7, Simon Giddings wrote: > > I am writing a music notation app for android tablets. > As I draw everything (ie. this is not a "simple" image (jpg, pdf, etc) > which needs displaying), I need to ensure that the choice of drawing method > is the fastest possible. > > My options, as I see them at present, are > > 1. Classic on-screen drawing. > 2. Draw on a memory based canvas and bitblt the resulting bitmap onto > the screen > > Will either option give better rendering time results ? > > I have chosen to use classic drawing methods, rather than an OpenGL type > surface. > Is this a mistake ? > > Any help will be appreciated. > Thank you > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
