Hey,
I have created the issue. It is Issue number 2794. Please look at it
and add extra comments if necessary. I agree with Bo, It is not possible to
do the option number 4. I think there are some changes that are required to
be incorporated in the jar file or provide us with a new API.
Regards,
Karan.
On Thu, May 28, 2009 at 3:27 PM, Bo <[email protected]> wrote:
>
>
>
> 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.
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
