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
