Hi Daniel, There are no Java <--> JNI boundaries, except where I call the top- level routine to do the image processing operation. Everything from there on is in C, and the native routine returns the resultant (filtered) image in a byte array.
And I did look at DDMS logs (on Android target, not on emulator). But not much I could gather from that. And I'll need to check out the Flyweight Java pattern -- I am doing so right now upon reading your reply :) Will update upon any progress! Thanks, Amit PS: May be unrelated, but here's an interesting couple of links (these are related to effects of JVM -- Dalvik -- on run-time performance, though not so much memory issues http://occipital.com/blog/2008/10/31/android-performance-2-loop-speed-and-the-dalvik-vm/ http://occipital.com/blog/2008/11/02/android-performance-3-iphone-comparison/ Of course, these entries are from 2008, so must be taken in that context. Dalvik VM has improved quite a bit, there's now support for FPU on Android. I read somewhere that FPU is enabled by default. As a side note, I also considered that in performance measurement; I was wondering whether to do fixed-point conversion of the code. But later found out that FPU is enabled, and in fact you should get an exception if you try to run floating point code on hardware without FPU. On Aug 19, 9:26 pm, Daniel Drozdzewski <[email protected]> wrote: > On Aug 19, 4:20 pm, Amit <[email protected]> wrote: > > > > > Hi Daniel, > > > Thanks for the response. > > > You are correct about the pitfalls of using the NDK. > > > However, the primary reason that I am using the NDK is pretty much the > > same as is mentioned in the NDK documentation. That is, legacy code. > > > Well, not quite, but the thing is that I have two development > > branches: for the PC and for the actual Android target. What I am > > doing is that since the debugging support is better on the PC, I try > > in new features (or algorithm optimizations) on the PC branch, and > > then on the Android branch. What the NDK helps me to do is to > > essentially use the same source for the Android branch. I do this by > > restricting myself to the headers for which support is stable (libc, > > math, etc. as documented by Google) and using #define switches for X86 > > and ARM code. > > > So your point is well taken, but using the NDK is helping me cut down > > on development time. > > > About the operations, the operations are basically filtering kind of > > operations. But my guess is that the processor stalls are causing the > > overall application to drag. Not in terms of responsiveness, as the > > computation runs as separate thread (not on the UI thread). But I > > would like the results of the processing to be available in a certain > > time due to UX constraints. > > > However, I will check out your suggestion about the Matrix class/ > > package. Haven't used it before, so I'll check it out. > > Matrix can be used in conjunction with Bitmap class to do coordinates > transformations (perspective changes, skew, scale, ...) so no > filtering unfortunately. > > Thanks for explaining further the nature of the problem. I don't think > I will be able to help (only basic graphical transformations done so > far), but I will definately keep eye on this thread as it is very > intresesting. > The only things that I can think of now are: > - Are you calling native code with each iteration, or is the whole of > that loop in native code? Crossing Java <-> JNI boundaries costs time. > - Also did you look at DDMS for memory alocations and garbage > collections on both emulator and the actual platform? With any > alocations within the loop and the number of pixels in a modest > picture, it will cost. > - Lastly: would you find use for Flyweight Java pattern that avoids > exactly allocations/dealocations? > > Good luck and please keep us posted! > > Daniel -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
