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, 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?
>>>>>>
>>>>> --
>> 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
>
>
--
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
