On May 28, 11:54 pm, Robert Green <[email protected]> wrote:
> 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.
I don't think this option 4 really works. The surfaceholder must be
set to SURFACE_TYPE_PUSH_BUFFERS to get camera preview. This would
create "a surface that doesn't owns its buffers. With such a surface
lockCanvas will fail."
Best,
Bo
>
> 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
-~----------~----~----~----~------~----~------~--~---
