I've written an Android module that does some very simple color swizzling on the pixels of an image. It drops the image to greyscale, bumps the contrast, and then screens it to a solid color.
The performance isn't too good. I've already written a native ObjC iOS module that does the exact same thing, and it's performance was excellent. But then, I'm an old C/C++/ObjC guy and I know my pointer arithmetic and native code optimization strategies. I also know Apple's Instruments app and am capable with it.
Trouble is, I don't know how to optimize Java code.
I did a basic port of my ObjC code. I pre-make contrast and tinting lookup tables, and then I create a pixel array from a bitmap decoded from the source blob, walk that computing indices into the lookup tables, and then bump that back into a bitmap.
I assume my main problem here is allocations. Creating immutable bitmaps, byte arrays, etc. It would be ideal if I could just walk a bitmap's pixels and not thrash the heap so hard.
Another option -- and one I think might be a lot better -- would be to run my code on a separate thread, and somehow invoke a callback when the processing is complete. But, I have no idea from the docs on how to do something like that ( or if it's even possible ).
Here's my complete module code. I'm open to any suggestions on how to make it faster.
So, I'm going to add something here - I had a hunch and tested if Ti.UI.ActivityIndicator works on its own thread ( I assume that the underlying Activity or window or whatever Android plumbing is running behind the scenes makes it work), and it does. The little spinner spins even while the main thread is blocking on the image processing code.
So, while I will still look into how to make my color manipulation code faster, I can at least now have a "Please wait..." spinner show up and let the user know that the app is not frozen.
So that's good!
I was able to speed it up by about 50% by using Android's ColorMatrix filter and compositing. No more manual pixel swizzling.
It's still balls-slow compared to the ObjC iOS implementation I wrote. But it's a lot faster than before, so that's something.
Think you can help? Login to answer this question!