[android-developers] Re: NDK: faster alternative to JNI based custom rendering

As you already pointed out, floats can be a bottleneck. In many cases it is possible to rewrite graphics algorithms in a way to make exclusive use of integers. You need to get rid of the fractional part and that can be done by scaling up all values depending on your needs for the precision. When all calculations are done you need to scale the numbers down again. Multiplications and especially divisions can be expensive, too of course. When your scale factor is a power of 2 you can use bit-shifting instead of multiplication and division which is computationally as cheap as it can get.

I wrote a small image processing and drawing library a while ago and wrote all algorithms to make use of integers. In case of convolution matrices it was possible to speed up the calculations up to 3 times compared to their floating point counterparts.

Another speed optimization trick is precomputing a table of reoccurring or known terms and values. This can be done with gradients for example. What I didn't dabble with yet is ARM's NEON extension. I read all over the place that (if used correctly) it can give you another significant speed boost. GCC provides some intrinsics for the extension. And as far as I know you can also tell GCC to automatically optimize for NEON. Since not all ARM CPUs are equipped with that extension this may be dangerous, though, unless you  create a version for NEON and a standard version and determine on runtime which one to load and use.

Android's RenderScript might be a pretty fast solution, too, but I'm not sure if you'll be able to easily convert your drawing algorithms to make it work with it. It's basically pretty good at crunching numbers and quickly running convolution matrices for image processing by using the GPU and theoretically all available CPU cores.


On Monday, October 14, 2013 7:28:29 AM UTC-5, Rick wrote:

Hello all,

I'm porting C/C++ based graphics project to Android where I need to transform dynamic graphical tree hierarchy(describing the screen content) from the C side to Android Java acitivity.

So far I tried following techinque:

1. call AndroidBitmap_lockPixels() in C

2. recurse thru the tree hierarchy and render every node to the locked bitmap in C

3. call AndroidBitmap_unlockPixels()

4. call canvas.drawBitmap() in the onDraw() of my Java activity View

This approach works relatively well but the main performance bottleneck(except the relativley frequent JNI calls) is the performance of the C rendering part which uses lot of floating point operations (using doubles) and therefore is not optimized for the ARM cpus.

Since the C rendering code does most of the graphics operations that are already built in the Canvas(Skia) frontend on the Java side I'm now thinking that maybe it could be possible to just somehow "serialize" the C graphical operations transfer them to Java side where they will be interpreted using the Canvas calls.

Also note the graphical structure at the C side can be changed during every render frame so I need to this quite frequently...

Is there any Android expert who have experience with simmilar problems? Does it make sense to try the alternative approach I decribed above? If so what is the fastest way to transfer/share such C data with Java? Or are there any other possible solutions?

Thanks in advance for any useful hints,

Rick

--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.