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
