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
