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.
