Karan, Option 1 is no good - only stubs are in Android.jar for things like that. Most of that code is native. You'd need a custom build of Android. If it was just an issue of java, you could write your own code but since it's native, you're right, portability is the problem.
Option 2 is no good - You can't really change the GC and you can't really control memory allocation for the thread. The fact of the matter is that 284k is being allocated for every frame in native code, and no amount of messing with stuff is going to change that. Option 3 works. Option 4 could be trying alternative ways of getting that data more efficiently. I was thinking that running it through a surfaceview and manipulating its bitmap might work. It's certainly a hack but it's worth a shot. On May 28, 12:25 am, karan parikh <[email protected]> wrote: > Hey All, > @Robert: Yes. I am talking about the same function call. If you read > the documentation for that, It says that a new copy is assigned everytime. > You could also verify it with the allocation tracker. It is assigning that > memory multiple times. > @Tom: Yes a new object reference is supplied each time. > My suggestions: > 1. We could implement a different jar file so that the frame gets > overwritten everytime. But then I believe this would remove the portability > from the application. > 2. We can change the garbage collector or play around with the memory > allocation for that very thread. I believe each thread has a generational > gc. We could further look into that. We could overwrite the memory for that > particular allocation each time, rather than freeing it and reallocating the > same. > 3. We can ask some one from google to look into it directly and create an > issue, which I will be doing by tonight. > Please let me know your suggestions to remove this bottleneck. > Thanks for commenting. > Regards, > Karan. > > > > On Tue, May 26, 2009 at 1:17 PM, Tom Gibara <[email protected]> wrote: > > I'm pretty sure I have looked into this in the past and found that a > > different object reference is supplied on each call. > > Tom. > > > 2009/5/26 Robert Green <[email protected]> > > >> Are you talking about the method Camera.PreviewCallback.onPreviewFrame > >> (byte[] arg0, anrdoid.hardware.Camera arg1) ? > > >> Is it allocating a new byte[] for every call? > > >> I would think it would keep its same byte[] and reuse it for each > >> call. > > >> Posting more code may help. Thanks > > >> On May 25, 9:30 pm, Karan Parikh <[email protected]> wrote: > >> > Hey All, > >> > I am developing a camera application , where the frame rate is > >> > important. However, camera uses a preview callback function which > >> > allocates a byte[] array of 230400 bytes, which makes it necessary for > >> > the garbage collection to step in. Can someone suggest me a way to > >> > avoid garbage collection stepping in ? > >> > Thanks in advance. > >> > Regards, > >> > Karan. > > -- > Regards, > -Karan. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
