I think low-level image processing in java will remain slow in this generation; if the 2d API can't do it for you, you might have to wait a gen.
But as for measuring performance, do we believe the emulator maps accurately to any particular hardware device? In the past, some emulators have shown very slow graphics/bitmap performance, because while the system anticipates (immutable) device-specific pixel formats, the emulator still needs another step to transform them to whatever graphics mode the emulator desktop is running in at the moment. I'd be interested in any information now available about performance on real hardware. It would be sweet if the emulator and toolchain eventually can simulate a performance profile for different hardware, even if the emulator real-time runs differently. I Of course, tons of hardware available with on-device profiling will be nice, too, but we all want to know what kind of app is feasible in the first generation of this. I hope a nice benchmark program emerges (or has emerged), and we can get the device results as early as possible. Jim On Apr 1, 11:02 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > You are timing your application by running, not by debugging, right? > Debugging the application through Eclipse takes significantly longer > than running it. > > Just wanted to make sure :) > > On Mar 30, 2:40 pm, mickrobk <[EMAIL PROTECTED]> wrote: > > > I feel your pain, when I do a generic flood fill it's taking 10s of > > seconds to walk through the array of pixels. I'm hoping memory access > > time will be reduced dramatically on a real device, or if it isn't jni > > is supported in some fashion. > > > On Mar 30, 11:10 am, saurabh <[EMAIL PROTECTED]> wrote: > > > > On Mar 30, 7:08 pm, David Given <[EMAIL PROTECTED]> wrote: > > > > > saurabh wrote: > > > > > [...] > > > > > > 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 to Bitmap B 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'd be inclined to copy all the pixel data out of the Bitmap into a > > > > int[] array of pixels; process it in-place; and then copy it all back in > > > > again. That way the heavy lifting --- the image processing --- occurs > > > > using simple array accesses, which should be way faster than doing > > > > method calls on Bitmap. > > > > Thanks. That makes sense. The getPixels() and setPixels() calls are > > > quite fast and I need to call them only once. However, iterating over > > > the int[] array and checking each value is taking a lot of time. I've > > > reduced the time of the app by half but that is just not good enough. > > > > > However... > > > > > > 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. > > > > > ...not a chance! > > > > > Hopefully this will be improved considerably when the JIT goes in, but > > > > right now simply filling an array of the right size with zeroes takes > > > > over a second. > > > > > (I recently had to do something similar; I eventually got around it by > > > > pushing all the image processing off into native code via JNI, which of > > > > course is not officially supported and probably not a good choice unless > > > > you really need it.) > > > > > -- > > > > ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────http://www.cowlark.com───── > > > > │ "I have always wished for my computer to be as easy to use as my > > > > │ telephone; my wish has come true because I can no longer figure out > > > > │ how to use my telephone." --- Bjarne Stroustrup > > > > > signature.asc > > > > 1KDownload --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
