Hacker News Reader

Comment by axod | Hacker News Reader

Comment #42

  It's a shortcoming of the graphics engine, complicated by
  the relative lack of memory and the trickiness with
  managing what little it has. The implementation in WebKit
  for GIF support allocates a 32 bpp bitmap for each
  frame, which can chew through memory very quickly. The
  bitmap allocator is backed by ashmem, but when the
  kernel detects low memory, it tends to kill the process
  rather than giving it a chance to back off.

  If you have expertise in this area, we'd gladly accept
  your help in fixing this.

View on HN

I'm curious how Apple managed to do it on devices that are substantially underpowered compared to many of the ones that make up the modern Android ecosystem.

I wouldn't say Apple's is any better. I've rarely ever had animated gifs work on my iPod. In fact, I don't ever remember a single one working. I might get a frame or two, at most, but that's it. Maybe they've fixed it in version 3 of the iPhone OS. I don't know, none of the features were worth the upgrade.

I've seen them work on my iPhone, but whatever algorithm they're using is horrible. For every frame of animation it seems to want to read from the "start" of the file. For a few frames, it's fine, but anything longer than 2-3 seconds of animation makes it slow to a crawl.

Animated gifs are so uncommon anyway (the use cases I've seen where it falls down are lolcat-worthy animations) that it's probably not worth fixing. The 90s-era gif animations probably look good enough.

Comment #45:

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

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.

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.

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.

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.

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.

Probably first by only allocating the necessary 8 bpp instead of 32 bpp

Reply on news.ycombinator.com