I was excited to try the bitmap-plasma sample included in the NDK, until I saw that the project requires Android 2.2 or higher. My goal is to be able to write something for android 2.1 using the NDK, that can somehow manipulate pixel data and get it to the screen. Is OpenGL the only possible option for graphics development in NDK targeting 2.1 users? Or is there maybe some other workaround besides the Bitmap interface in 2.2.
On Thu, Jul 15, 2010 at 12:15, Hans L <theh...@gmail.com> wrote: > I was excited to try the bitmap-plasma sample included in the NDK, until I > saw that the project requires Android 2.2 or higher. > My goal is to be able to write something for android 2.1 using the NDK, > that can somehow manipulate pixel data and get it to the screen. > Is OpenGL the only possible option for graphics development in NDK > targeting 2.1 users? Or is there maybe some other workaround besides the > Bitmap interface in 2.2.
You can create arrays of pixel data and pass it to/from JNI functions easily enough - and then use Android Bitmap functions like copyPixelsFromBuffer or setPixels. These all involve an extra copy to use unfortunately, which is why the froyo bitmap functions were added. There are also annoying limitations in the Bitmap API when used with JNI, like no way to do partial updates from a Buffer, etc.
I wouldn't suggest OpenGL for this purpose, since based on my tests, for simple 2D rendering, the direct Surface drawing is much faster.
You can pass the pixel data through Java NIO to the Java layer for painting, which performs very well compared to ByteArray approach.
The Java Bitmap itself does some memory copying, and even color space conversions, so if you have your pixel data in RGB565 color space you can prevent these steps as well. When I did a few tests on a Motorola Droid, I was able to achieve 230 fps with VGA using RGB565 color space. Using ARGB 16bit about 82 fps, and ARGB 32 bit about 140 fps.
There are few other ways, but these are the only options available through the public API.
On Wed, Jul 14, 2010 at 7:15 PM, Hans L <theh...@gmail.com> wrote: > I was excited to try the bitmap-plasma sample included in the NDK, until I > saw that the project requires Android 2.2 or higher. > My goal is to be able to write something for android 2.1 using the NDK, > that can somehow manipulate pixel data and get it to the screen. > Is OpenGL the only possible option for graphics development in NDK > targeting 2.1 users? Or is there maybe some other workaround besides the > Bitmap interface in 2.2.
> -- > You received this message because you are subscribed to the Google Groups > "android-ndk" group. > To post to this group, send email to android-ndk@googlegroups.com. > To unsubscribe from this group, send email to > android-ndk+unsubscribe@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/android-ndk?hl=en.
On Thu, Jul 15, 2010 at 12:10 AM, Onur Cinar <onur.ci...@gmail.com> wrote:
> Hi Hans,
> I wouldn't suggest OpenGL for this purpose, since based on my tests, for > simple 2D rendering, the direct Surface drawing is much faster.
> You can pass the pixel data through Java NIO to the Java layer for > painting, which performs very well compared to ByteArray approach.
> The Java Bitmap itself does some memory copying, and even color space > conversions, so if you have your pixel data in RGB565 color space you can > prevent these steps as well. When I did a few tests on a Motorola Droid, I > was able to achieve 230 fps with VGA using RGB565 color space. Using ARGB > 16bit about 82 fps, and ARGB 32 bit about 140 fps.
> There are few other ways, but these are the only options available through > the public API.
> Regards,
> -onur
Thanks for the reply, but I'm very new to this, and your post is too vague for me to understand what methods you are referring to exactly. What do you mean by the ByteArray approach? Is that even a class? Or are you literally talking about "byte[]"?
Could you possibly give a snippet of example code or even just name the class methods that you are using? What dataype exactly are you passing back and forth to native code?
On Thu, Jul 15, 2010 at 11:59 PM, Hans L <theh...@gmail.com> wrote: > On Thu, Jul 15, 2010 at 12:10 AM, Onur Cinar <onur.ci...@gmail.com> wrote:
>> Hi Hans,
>> I wouldn't suggest OpenGL for this purpose, since based on my tests, for >> simple 2D rendering, the direct Surface drawing is much faster.
>> You can pass the pixel data through Java NIO to the Java layer for >> painting, which performs very well compared to ByteArray approach.
>> The Java Bitmap itself does some memory copying, and even color space >> conversions, so if you have your pixel data in RGB565 color space you can >> prevent these steps as well. When I did a few tests on a Motorola Droid, I >> was able to achieve 230 fps with VGA using RGB565 color space. Using ARGB >> 16bit about 82 fps, and ARGB 32 bit about 140 fps.
>> There are few other ways, but these are the only options available through >> the public API.
>> Regards,
>> -onur
> Thanks for the reply, but I'm very new to this, and your post is too vague > for me to understand what methods you are referring to exactly. What do you > mean by the ByteArray approach? Is that even a class? Or are you literally > talking about "byte[]"?
> Could you possibly give a snippet of example code or even just name the > class methods that you are using? What dataype exactly are you passing back > and forth to native code?
> Hans
> -- > You received this message because you are subscribed to the Google Groups > "android-ndk" group. > To post to this group, send email to android-ndk@googlegroups.com. > To unsubscribe from this group, send email to > android-ndk+unsubscribe@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com> > . > For more options, visit this group at > http://groups.google.com/group/android-ndk?hl=en.
