I leave it as an exercise for the reader to establish whether it is efficient or convenient to do so, but the graphics.Matrix class certainly can be used to implement linear filtering operations (e.g, IIR, FIR). I am also sure that the class would be much more convenient if it would support arbitrary matrices instead of only 3x3!
That said, clearly the graphics.Matrix class was not designed for this: it was designed for the linear transformations most commonly used in 2D graphics, that is, those of homogeneous coordinates for a two-dimensional space (so that all geometric transformations can be represented by linear transformations). On Aug 19, 9:26 am, 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
