Have you considered or tried using:

 
Canvas.drawBitmapMesh<http://developer.android.com/reference/android/graphics/Canvas.html#drawBitmapMesh%28android.graphics.Bitmap,%20int,%20int,%20float[],%20int,%20int[],%20int,%20android.graphics.Paint%29>
?

Maybe you can fake flame flickering by animating mesh vertices instead.


On Tuesday, July 17, 2012 2:58:50 PM UTC-5, Matt Schoen wrote:
>
> 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

Reply via email to