Re: [android-developers] Re: Forcing lower resolution drawables on phones with big screens and small RAM
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%
Re: [android-developers] Re: Forcing lower resolution drawables on phones with big screens and small RAM
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,
Re: [android-developers] Re: Forcing lower resolution drawables on phones with big screens and small RAM
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
Re: [android-developers] Re: Forcing lower resolution drawables on phones with big screens and small RAM
Maybe I'm wrong, but I think he pointed that the frame sequence depends on user input, so he cannot preload a series of frames because each next frame varies with user interaction on previous one. On Jul 17, 2012 6:51 PM, Nobu Games dev.nobu.ga...@gmail.com 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
