After copying all the pixels to int[], I iterate over the int array and check if each element satisfies a condition. I tried optimizing the code by removing as many floating point operations and divisions as possible. This has helped me reduced the time further by approx 5 seconds.
On Apr 2, 4:02 am, tomgibara <[EMAIL PROTECTED]> wrote: > Doing pixel-level processing in within the Dalvik VM will necessarily > incur the overhead of copying the pixel data into the VM heap. As > others have suggested, this needs be done to gain fast access to the > pixel data. > > But I doubt that this is the bottleneck, it's certainly the > interpreted nature of the Dalvik VM. There's a useful detailed post > about the overhead here: > > http://groups.google.com/group/android-developers/browse_frm/thread/6... > > If my understanding is correct, this means that an operation like an > integer add costs 1 CPU cycle, but the VM adds an overhead of > approximately 20 cycles to every instruction, so code which has a > performs a large number of fast operations (such as image processing) > is going to be very badly penalized. > > To put this more clearly, lets hypothesize that a method call takes 20 > CPU cycles (I've plucked that figure out of mid-air) then the > interpreter overhead means that an integer add is only twice as fast > as a method call. This is going to skew performance characteristics > dramatically away from the norms that developers expect. > > But I think there are reasons to be hopeful. In this post, Dan Morrill > indicates that "a just-in-time compiler is definitely on the Dalvik > roadmap": > > http://groups.google.com/group/android-developers/browse_frm/thread/c... > > I don't know where on the roadmap, that might be. Also the potential > benefits of a JIT are probably very difficult to prejudge (due to > issues that are beyond my experience, such as cache considerations). > Nevertheless I did a very quick analysis using the data here: > > http://shootout.alioth.debian.org/ > > I compared, Sun's interpreter against Sun's hotspot compiler and chose > the median of the execution-time ratios. This (totally ridiculous) > procedure gave me a figure of about 8x speed improvement (of course > this figure will differ dramatically based on the application and many > other factors). It was just a very quick way to get an estimate > without actually needing to write an AOT or JIT compiler which would > be the only reliable way. > > I've gone a bit off topic, but I just thought some background might > help. > > Tom. > > On Mar 30, 12:19 pm, saurabh <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I am working on an image processing application. The job is simple: > > > 1. read an image into aBitmapobject A, > > 2. create a newBitmapobject B of the same dimensions, > > 3. iterate overBitmapA examining each pixel and copying it to B if > > it satisfies some conditions, > > 4. displayBitmapB using ImageView. > > > The trouble is that though the application is working correctly, it is > > tooslowto use. For a JPEG image of 547x450 resolution, the > > application takes 66 seconds to produce the final output. The getPixel > > function seems to be taking approx 1/100 of a second. Similarly, > > checking whether each pixel satisfies the condition and then copying > > it toBitmapB also takes approx 1/100 second. Therefore, performing > > these 2 operations for 547*450 = 246150 pixels takes a lot of time. Is > > there any way to do this faster? I hope to use this for processing > > each frame of a video in real-time. So, processing each picture must > > not take more than a 1/20 of a second. --~--~---------~--~----~------------~-------~--~----~ 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] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
