4 ms·

Comment #45: According to the Android developer in comment 42 the explanation is that Android has multitasking while the iPhone doesn't.

houseabsolute 17y ago
Not really understanding what short of a truly massive design flaw could cause these two things to be related. Surely if we're running low on memory the backgrounded processes should be the first ones to get killed. Or else how can you make an app that when active pushes the limits of the device? You'd always be worried about getting killed and not about doing what your app is there to do.
- axod 17y ago
  Also surely you could just have: function readGIF(filename) { if (calcMemSizeNeeded(filename) > memoryFree()) { displayGifPlaceholder(); } } eg just display an animated GIF if there's enough ram, and if not, display some placeholder. I guess one of the other issues there though is websites that 'stream' animated gifs that never end. Still, you could just disable those for now.
- regularfry 17y ago
  What if there's a bug in the foreground process that eats memory? In that case, you don't want to start killing off background processes at random, or you'll get a dead phone. Seriously, google "OOM killer." This problem, and problems like it, are not new, nor are they simple to solve.
  - houseabsolute 17y ago
    I'm aware of what an OOM killer is, but it strikes me that the rules are a little different on a device where the resource constraints and mode of operation will frequently demand all the resources for a single process.
viraptor 17y ago
That's just silly explanation. They have enough processing power to decode every frame into the single-frame buffer every time a new one is needed. Why preallocate the whole movie? I guess they don't do it the same way for videos anyways... Also, I'm not sure where did commenter #45 get the idea about multitasking. #42 said just that process which is memory-hungry will be killed. That's it. It doesn't matter if the OS is multitasking or not... Maemo is multitasking (linux based) and displays animated GIFs just fine.

houseabsolute 17y ago

Not really understanding what short of a truly massive design flaw could cause these two things to be related. Surely if we're running low on memory the backgrounded processes should be the first ones to get killed. Or else how can you make an app that when active pushes the limits of the device? You'd always be worried about getting killed and not about doing what your app is there to do.

axod 17y ago
Also surely you could just have: function readGIF(filename) { if (calcMemSizeNeeded(filename) > memoryFree()) { displayGifPlaceholder(); } } eg just display an animated GIF if there's enough ram, and if not, display some placeholder. I guess one of the other issues there though is websites that 'stream' animated gifs that never end. Still, you could just disable those for now.
regularfry 17y ago
What if there's a bug in the foreground process that eats memory? In that case, you don't want to start killing off background processes at random, or you'll get a dead phone. Seriously, google "OOM killer." This problem, and problems like it, are not new, nor are they simple to solve.
- houseabsolute 17y ago
  I'm aware of what an OOM killer is, but it strikes me that the rules are a little different on a device where the resource constraints and mode of operation will frequently demand all the resources for a single process.

viraptor 17y ago

That's just silly explanation. They have enough processing power to decode every frame into the single-frame buffer every time a new one is needed. Why preallocate the whole movie? I guess they don't do it the same way for videos anyways... Also, I'm not sure where did commenter #45 get the idea about multitasking. #42 said just that process which is memory-hungry will be killed. That's it. It doesn't matter if the OS is multitasking or not... Maemo is multitasking (linux based) and displays animated GIFs just fine.