I used to use BitmapFactory.decodeStream for creating Bitmaps from raw
assets.
Just guessing, may be you can load each bit map, show it in the fly, and
recycle it before loading next one.
El 19/07/2012 04:12, "Matt Schoen" <mtsch...@gmail.com> escribió:
>
> Drat.
>
> I was able to get this to work, but now it just always runs out of
memory! I guess this method is less memory-efficient? Here's the code
being executed:
>
>>> for(int i = 0; i < total_animation_length; i++)
>>>
>>> imageResources[i] =
Drawable.createFromResourceStream(context.getResources(), new TypedValue(),
context.getAssets().open("flame_high/" + String.format(file_name, i)),
"test");
>
>
> On Wednesday, July 18, 2012 6:09:46 PM UTC-4, Fran wrote:
>>
>> Use they Assets folder instead. Take a look on AssetManager docs.
>>
>> El 17/07/2012 22:00, "Matt Schoen" <mtsch...@gmail.com> escribió:
>>>
>>> Unfortunately I've already done your last suggestion. The images are
pretty small already. I'm still not convinced that the streaming would
work. For one thing, the flicker loops, and for another, the range of
frames changes quite often. For example:
>>>
>>> If the phone starts upright, we play images 90, 91, 92, 93, 94, 95, 90,
91...
>>>
>>> Then, if you til it, it'll be like 90, 91, 92, 80, 81, 82, 60, 61, 62,
40, 41, 120, 121, 140, 141...
>>> ^
^ ^ ^ ^
>>>
>>> The carats signify where the accelerometer value has changed so that
the "first" frame is different. This happens quite frequently (to make for
a smooth "bend") and is completely unpredictable. As far as I can tell,
we'd always get a hiccup when the accelerometer value changed.
>>>
>>> I'm really hoping that I can do what I was originally asking for. It
seems so simple to just force the loading of a different set of drawables.
>>>
>>> If I wanted to load the images some other way (not through the
drawables folder) how could I do that?
>>>
>>> On Tuesday, July 17, 2012 12:48:48 PM UTC-4, Nobu Games wrote:
>>>>
>>>> You still could go with the "streaming" idea. At any given time you
would have a fixed size amount of frames in memory (let's say 15 bitmaps,
just as an example). As the animation progresses you need to load the next
batch and discard older ones. In order to prevent loading hickups you could
proceed as follows:
>>>> Your "window" of animation bitmaps has 15 items.
>>>> As the animation counter reaches item #6 you would recycle the last 5
ones and load the next 5 ones that come after item #15
>>>> Loading needs to be done in a background thread (AsyncTask)
>>>>
>>>> Of course you'd need to add special logic for your case, like allowing
to loop a certain amount of animation frames and starting playback from any
point of the sequence and so on. But this could be done with a fixed size
window of frames.
>>>>
>>>> I think that's the only sane way to do that based on that huge bitmap
sequence and you could even adjust the window size according to the
available memory. Play around with these numbers in order to get the best
result for your animation.
>>>>
>>>> By the way, I would just animate the flame itself and use a single,
static bitmap for the lighter. That way you could use a low-resolution
bitmap sequence of the flame and scale it up on devices with less memory.
Lights and shadows could be faked in real time, too, by drawing overlays on
the view's canvas.
>>>>
>>>> Maybe you can get away with that solution and don't need to implement
a streaming technique.
>>>>
>>>>
>>>> On Tuesday, July 17, 2012 9:28:59 AM UTC-5, Matt Schoen wrote:
>>>>>
>>>>> Hey, thanks for the reply.
>>>>>
>>>>> I guess I should have explained more clearly. This is a "lighter"
type animation, which responds to accelerometer input. The flame flickers
(plays from a start frame on a short loop) and when you tilt the phone, the
start frame is "swept" through an animation of the flame bending from one
side to another.
>>>>>
>>>>> Because of this, I'm not sure I could really "stream" anything since
I might need any one frame of the animation at any point. It just occurred
to me that maybe I could store only half the frames and flip them in
software (currently the "flip" is just rendered into the animation).
>>>>>
>>>>> This is why I'm just using a big image sequence (about 150 frames) as
drawables. Any advice?
>>>>>
>>>>> On Saturday, July 14, 2012 12:26:13 PM UTC-4, Nobu Games wrote:
>>>>>>
>>>>>> How many items are in your animation list? If it is really, really
huge I'd add some "streaming" logic to your animation player, so older
frames get recycled while future frames are loaded in the background. That
way you have absolute control over a moving window of frames and you could
size that window according to the available amount of free memory. You
wouldn't risk OOM crashes on any device with that technique.
>>>>>>
>>>>>> Alternatively you could create a video based on your frames and play
that one back instead.
>>>>>>
>>>>>>
>>>>>> On Friday, July 13, 2012 10:54:46 PM UTC-5, Matt Schoen wrote:
>>>>>>>
>>>>>>> Hey there,
>>>>>>>
>>>>>>> I've tried to find info on this, but it seems like a pretty
esoteric case. I'll admit that I'm probably completely off-base to start,
but the app is 99% done, so I'd rather not change my implementation from
it's current state. I have an animation that I'm using a big list of
drawables to display, and while it works fine on phones with enough RAM, I
get "VM out of memory" crashes on devices with basically 512 MB RAM and
below.
>>>>>>>
>>>>>>> I've found the getMemoryClass() function, which seems to report
"32" for a device with 512MB. I tried overriding the density value, which
successfully avoided the crash, but also resized my whole view! All I want
is to be able to programmatically tell the view framework to default to the
low-res images. Is this possible?
>>>
>>>
>>> On Tuesday, July 17, 2012 12:48:48 PM UTC-4, Nobu Games wrote:
>>>>
>>>> You still could go with the "streaming" idea. At any given time you
would have a fixed size amount of frames in memory (let's say 15 bitmaps,
just as an example). As the animation progresses you need to load the next
batch and discard older ones. In order to prevent loading hickups you could
proceed as follows:
>>>> Your "window" of animation bitmaps has 15 items.
>>>> As the animation counter reaches item #6 you would recycle the last 5
ones and load the next 5 ones that come after item #15
>>>> Loading needs to be done in a background thread (AsyncTask)
>>>>
>>>> Of course you'd need to add special logic for your case, like allowing
to loop a certain amount of animation frames and starting playback from any
point of the sequence and so on. But this could be done with a fixed size
window of frames.
>>>>
>>>> I think that's the only sane way to do that based on that huge bitmap
sequence and you could even adjust the window size according to the
available memory. Play around with these numbers in order to get the best
result for your animation.
>>>>
>>>> By the way, I would just animate the flame itself and use a single,
static bitmap for the lighter. That way you could use a low-resolution
bitmap sequence of the flame and scale it up on devices with less memory.
Lights and shadows could be faked in real time, too, by drawing overlays on
the view's canvas.
>>>>
>>>> Maybe you can get away with that solution and don't need to implement
a streaming technique.
>>>>
>>>>
>>>> On Tuesday, July 17, 2012 9:28:59 AM UTC-5, Matt Schoen wrote:
>>>>>
>>>>> Hey, thanks for the reply.
>>>>>
>>>>> I guess I should have explained more clearly. This is a "lighter"
type animation, which responds to accelerometer input. The flame flickers
(plays from a start frame on a short loop) and when you tilt the phone, the
start frame is "swept" through an animation of the flame bending from one
side to another.
>>>>>
>>>>> Because of this, I'm not sure I could really "stream" anything since
I might need any one frame of the animation at any point. It just occurred
to me that maybe I could store only half the frames and flip them in
software (currently the "flip" is just rendered into the animation).
>>>>>
>>>>> This is why I'm just using a big image sequence (about 150 frames) as
drawables. Any advice?
>>>>>
>>>>> On Saturday, July 14, 2012 12:26:13 PM UTC-4, Nobu Games wrote:
>>>>>>
>>>>>> How many items are in your animation list? If it is really, really
huge I'd add some "streaming" logic to your animation player, so older
frames get recycled while future frames are loaded in the background. That
way you have absolute control over a moving window of frames and you could
size that window according to the available amount of free memory. You
wouldn't risk OOM crashes on any device with that technique.
>>>>>>
>>>>>> Alternatively you could create a video based on your frames and play
that one back instead.
>>>>>>
>>>>>>
>>>>>> On Friday, July 13, 2012 10:54:46 PM UTC-5
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
