That's right but there is some limitation though. I can't find a way to zoom
on a detail of an hires JPEG, for example.
Kevin
On Fri, Jun 25, 2010 at 8:41 AM, Sebastian Roth wrote:
> Hi Kevin:
>
> I think the memory for high megapixel images is not so important because u
> usally will stream th
Hi Kevin:
I think the memory for high megapixel images is not so important because u
usally will stream the image through a InputStream onto disk. You can then
read the image via BitmapFactory and set a inSampleSize to retrieve it.
BR,
Seb, starting up a WIKI for android memory issues..
On Fri,
Hi Romain,
Is there a list somewhere of devices with 24Mb per process ? Is there
a way to adjust this in the emulator ? Is there an API method allowing
to know the total memory available for the process ?
I'm writing a pictures manipulating app, and handling hires pics is
hard with only 16Mb. New
None of the tools I know work well with images and I'm not sure how to
improve that. One way might be to use adb shell tools like dumpsys and
compare the numbers over time, I heard. Not very convenient.
I'm checking the difference between PNG8 and PNG24 now. From my
understanding this could save s
Are any of those tools helpful with bitmaps?
I've analyzed an HPRof where all the bitmaps are taking up32 bytes.
that would be nice if it were true. I know that bitmaps are not on the
regular heap, so the tools don't seem to find them.
Since the bitmaps are marked as purgeable, they could be taki
You catch out of memory? I wasn't willing to do that yet, but it
would solve all my problems...
On Dec 11, 7:09 am, Streets Of Boston wrote:
> >>If you're nulling your static bitmap in onPause why is it static to begin
> >>with?<<
>
> E.g. to have access to bitmaps outside of my activity, in cl
>>If you're nulling your static bitmap in onPause why is it static to begin
>>with?<<
E.g. to have access to bitmaps outside of my activity, in classes that
don't have reference to my activities.
Or, in case there can be multiple instance of an activity, these
instances can share 'expensive' dat
Hi Matt,
you could try explicitly freeing the resources your bitmaps use by
invoking Bitmap.recycle(). The description of this method reads
"Free up the memory associated with this bitmap's pixels, and mark the
bitmap as "dead", meaning it will throw an exception if getPixels() or
setPixels() is
I don't get it. If you're nulling your static bitmap in onPause why
is it static to begin with?
Also what you want to do is probably very different for a game that is
basically all taking place in one activity and trying to avoid garbage
collecting at all, compared to your standard Android app wi
Statically held (caches of) bitmaps may come in very very handy.
However, as soon as you do hold static references to 'expensive'
resources, be sure to have a proper clean-up strategy. E.g. make sure
the capacity of your cache of bitmaps is limited. Be sure to set the
static reference to null when
I recommend the only things you make static be strings, and that for
everything else you are considering making static, instead write it to
file and use static methods, that expect to be passed a context, to
access the data.
I think my problems might be camera related, so my plan is to stop
using
On Dec 8, 12:28 pm, skominac wrote:
> So not only is memory of static members not deallocated (which is
> actually not surprising), but the static references are still alive,
> pointing to the memory, and can be used to invoke the members back.
> This last part was surprising to me.
>
> This is ac
It appears that static members of activity remain allocated and
referenced between consecutive runs of Activity. I can actually draw
the bitmap from the previous launch -- in a new launch (between finish
() calls). It's still there.
So not only is memory of static members not deallocated (which is
On Dec 6, 10:23 pm, Romain Guy wrote:
> How come you still have a reference to your bitmap when a new Activity
> is created?
That confuses me, too, actually. I really want to find out how I made
this happen.
> If you have this bitmap somewhere else than within the
> Activity, then it's perfect
How come you still have a reference to your bitmap when a new Activity
is created? If you have this bitmap somewhere else than within the
Activity, then it's perfectly normal that it's not de-allocated when
the Activity disappears. In addition, if your Activity is not garbage
collected, you probabl
I had a similar issue. Calling "finish()" on Activity does not in
itself deallocate memory allocated in Activity. The reason we notice
this problem with bitmaps is because they are often so large.
Recycling bitmaps did not work for me either.
So, instead, when my Activity starts, and before I cre
Hi Matt,
I'm not aware of any other source. This we learned on our own on Friday,
November 6th (Droid release day :-)
To put it simply, say I have a 64x64 .png resource and use:
Bitmap b = BitmapFactory.decodeResource(...)
I will get a 64x64, 32-bit in-memory bitmap.
If I use the exact same co
"My" app involves taking a picture with the camera, or recording voice
using the microphone, and sending the results to the server. It's a
search tool. The UI isn't very complicated, as much as possible it is
done in XML. For the droid we added some layouts in res/long that
differ only in layou
The bitmap issue on the Droid is really about whether you want to show more
graphics at smaller size, or the same graphics at larger size.
I don't know what you app does, but imagine that it's a 2d game, where the
graphics are re-used a lot (land tiles, character icons, etc.).
If you let the high
IMHO, if the device offers 50% more memory per application, but the
bitmaps take up more than 50% more memory, then the net effect is a
stricter limitation.
i'm seeing some occasional OOMs only on Droid, and so i'm being extra
careful about recycling bitmaps and all that.
At 5:40 PM -0800 12/
The same code works great on the G1 and the MyTouch. We've done some
testing on the Hero, and the Moment, but only on the Droid is the
issue significant. I've told my boss that I am spending time porting
to the Droid.
You have explained that "bitmaps are scaled and require more memory".
This cre
The new device does not have stricter limitations since it gives apps
more RAM (24 MB instead of 16 MB.)
On Wed, Dec 2, 2009 at 5:29 PM, Matt Kanninen wrote:
> What did I do wrong? I worked within the defined limitations, then a
> new handset came out with stricter limitations.
>
> I'm kind of c
What did I do wrong? I worked within the defined limitations, then a
new handset came out with stricter limitations.
I'm kind of confused how you can blame me!
On Dec 2, 5:19 pm, Romain Guy wrote:
> The Droid has more pixels and a high display density, therefore
> bitmaps are scaled and require
The Droid has more pixels and a high display density, therefore
bitmaps are scaled and require more memory. If your app is running out
of memory, do not blame it on the framework and "poorer performance,"
blame it on your app for doing the wrong thing and abusing the Java
heap.
> The app worked gr
The app worked great on the G1. I've clearly hit a case where the
framework made some decisions that result in poorer performance on the
Droid.
The bitmap out of memory errors can still occur on any setLayout(res/
xml/id), after running the app for 5-30 mins. But I did fix the
bitmap out of memo
Thank you, this is exactly the sort of workaround I was looking for.
I just filed the Media Recorder release bug, since the first bug got
closed so fast.
http://code.google.com/p/android/issues/detail?id=5047
On Nov 25, 11:43 am, Matt Hall wrote:
> Yeah, we've had a similar issue before. One th
Yeah, we've had a similar issue before. One thing you can try is to call
recycle() on the last frame of your animation before you replace it. This is
normally called by the garbage collector and works fine when you're not
close to the memory limit, but it sounds like there might be cases where you
Matt,
So in this case I definitely am frequently loading and unloading small
images. Those 10 id's all point at different states in our
animation. I can reduce the quality of our animation by reducing the
views, and decrease how often I stumble down this cow path:
but I only posted this stack t
Great guesses!
This happens randomly through my application, every half hour on a G1,
every 5 mins on the droid. The error happens randomly, usually in
setContentView, per another post of mine.
On Nov 25, 11:11 am, Streets Of Boston
wrote:
> As in the comment in your bug-report by Romain, you'r
As in the comment in your bug-report by Romain, you're using too much
memory.
Note that you only have 16MByte total available RAM for your process,
including your bitmaps.
- Only load the bitmaps that are absolutely necessary (especially when
they become quite large).
- Load the bitmaps scaled to
How big (dimensions) are the graphics Matt? If they're not very big
then I'm guessing you have bitmap memory used elsewhere in the app
that's putting you close to the max. Bitmap memory is different than
your heap memory, so it's management is hidden from you a little more
but basically this error
http://code.google.com/p/android/issues/detail?id=5045";>Issue
5045
http://code.google.com/p/android/issues/detail?id=5045
On Nov 25, 9:37 am, Matt Kanninen wrote:
> This:
> private static final int[] glowDrawableIds={
> R.drawable.graphic_microphoneglow_01,
>
I do this in my app as well, and it works fine using BitmapFactory.
But i make sure that this large bitmap (full-size image, 6Mpix) is
about the only one loaded in my application. If not, i get the same
exception.
Opening 2 of these large ones will give me this exception, whatever i
do.
On Apr 2
I've tried the unbind method and it doesnt seem to help my case :( It
is a good thing to know and keep in mind.
Rohit
On Jan 23, 2:07 pm, JP wrote:
> There's a bunch of discussions about this issue in this forum, just
> dig a little and you will find what you need to know.
> Also, Romain Guy p
There's a bunch of discussions about this issue in this forum, just
dig a little and you will find what you need to know.
Also, Romain Guy posted a write-up about un-binding views (and
bitmaps) from activities.
http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html
Admittedly,
It seems that there my be a bug, memory leak with the BitmapFactory
when decoding, and reading bitmaps from file. I, and many other
developers have noticed similar problems to what you describe. I
haven't been able to get any official confirmation that this is a
known bug, but it looks like a b
36 matches
Mail list logo
