Bug 22280 – CG GIF decoder uses too much CPU

• Status: RESOLVED
• Resolution: FIXED
• Component: Images

[Kevin M. Dean]

r37605 - performance is fine
r37698+ - performance drops.

I've removed the flash plugin during testing to remove it's performance hit from the equation.

When loading the site above, there's an animated gif in the upper left corner that I believe is the source of the issue. Sitting on the page, the responsiveness of Safari begins to decrease. The best way to begin to see this is to use your scroll wheel to scroll the animated gif off and then back on the screen repeatedly. You should begin to notice the scrolling becomes more and more sluggish and glitchy. Also, you'll notice rolling over the bookmark bar links becomes sluggish with the gif on screen. Eventually I start seeing the spinning color wheel making everything un-responsive. Then it the wheel comes and agos as the performance seems to cycle up and down and  cpu usage starts to peg. You can try to close the tab or quit and eventually it will do so and then normal performance returns. This site uses very large animated gifs which might be what separates this from other sites with gifs.

[Matt Lilek]

Definitely confirmed.

On my system (MBP 2.5GHz Core 2 Duo, 4 GB RAM, 10.5.5 9F33), playing the standalone gif in r37605 only peaks my CPU at 70% after playing it all the way through.  With r37698, my CPU spikes to 100% only a little ways into it.

[Peter Kasting]

r37612 has a known perf decrease with certain animated GIFs which is unavoidable: the old code was not animating GIFs fast enough, so since the new code is doing more work, it can consume more resources.

At the time I checked in this code, I mentioned this to hyatt.  In most cases I saw the problem was due to the CG GIF decoder apparently re-decoding from the beginning of the stream on any frame, instead of doing as little work as possible to move from the prior frame(s) to the current one.  (This is something of a simplification.)  Not sure if any bug got filed in radar about that.

If this is the source of the bug, I don't think we can easily address it on the WebKit side.  It may need to be fixed in image decoder land.  Another possibility would be to move from the CG decoders to one in the WebKit tree (e.g. the Chromium decoders) but I doubt that would go over well; I think Apple has a number of reasons to prefer the CG decoders in Safari.

[Kevin M. Dean]

Either way it seems really silly that an animated gif would even take 70% on a MBP 2.5GHz Core 2 Duo much less pegged at 100% and making the app unresponsive. What is taxing the cpu so much when it's basically a slideshow being played. One would think considering how long animated gifs have been around that they would fairly trivial to playback at low cpu usage.

[Peter Kasting]

I have a local patch that allows me to address the Chromium version of this issue.  CPU went from being pegged at 100% on my test GIF to 0-1%.  As-is, the patch wouldn't fix Safari (which uses a different GIF decoder than Chromium) but would put in framework that could allow the issue to be fixed later.

[Peter Kasting]

The patch is now up on bug 22108.  Sadly, it will not help Safari as-is.

Random note: Even if you entirely disable the code that drops references to old frames for large GIFs, this GIF still eats CPU in Safari.  I see no reason why it should; this seems like a clear bug in the CG GIF decoder.

[Peter Kasting]

I'm morphing this bug to make it clear that the underlying issue is the CG decoder (as far as I can tell), and that this is not something which worked great before but doesn't anymore.  From comment 1, the "old behavior" peaked the test system at 70% CPU.  Animated GIFs should consume less than 5% of a CPU.

I believe my findings in comment 5 indicate that for this image, the CG decoder is redecoding from the beginning on every frame.  This shouldn't be needed when the decoder still has references to previous frames.

The framework on bug 22108 is now in place, if it becomes useful in the future; however, without fixing the behavior noted in comment 5, it won't help anything.

[Kevin M. Dean]

Anybody ever hear from the Safari team regarding this. I'm getting really tired after at least 8 months of seeing the spinning wheel whenever I hit a stupid animated gif. It's ridiculous and makes Safari look like crap. I've submitted a Safari bug report in the past and again today and it's silly they haven't done squat about this in all this time.

[Shamil Kerimov]

Agree with previous commentator - I have added all of my 10 votes for this bug, but yet nothing happened. Please fix it.

[Peter Kasting]

According to bdash on IRC, this issue has been fixed in SnowLeopard.  I suggest retesting once that comes out.

[Kevin M. Dean]

Wow, Snow Leopard? ....really. Some of us can't upgrade to Snow Leopard so they should really get off their butts and fix it for Leopard as well, since it didn't used to always be broken in the first place.

[Peter Kasting]

(In reply to comment #10)
> it didn't used to always be broken in the first place.

Yes, it did.

As noted on comment 2, the decoders always had heavy CPU usage.  The only mitigating factor was that they also decoded animated images far too slowly (sometimes taking more than twice as long as desired).  That doesn't mean that they "didn't use to be broken", it meant that one bug lessened the negative impact of another bug.

[Kevin M. Dean]

I'm just speaking to the specific issue where animated gifs didn't use to make the browser completely unresponsive just by appearing on the page as they often do now. I can be scrolling down a web page and even before I see the gif, the color spinning wheel will appear for a random amount of time and then the screen will eventually finish scrolling the gif on to the screen. Then with really big animated gifs, sometimes everything remains sluggish with more spinning wheel until I scroll the gif off screen or leave the page. Shouldn't need the latest unreleased OS to manage basic 20 year old web tech properly. Whatever the case, they need to apply the fix to current versions of the OS that the bug affects. It can't be that difficult to resolve.

[Knodi]

Are you kidding me wait for OS upgrade for fix your browser freezing up on gifs??

What are you fucking microsoft??

[Alexei Yudin]

If nobody fixes this annoying bug, i swear I'm going to kill a bunch of innocent people, and Webkit developers will be the ones to blame!

Seriously, it's rediculous how one tiny gif freezes the whole browser. It's 2009, goddamnit! Ask the folks from Firefox for fuck's sake, because their browser renders gifs perfectly.

[Kevin M. Dean]

I'm glad others have finally started to notice this stupidity. I've seen the issue mentioned in discussions of the latest Safari releases as well outside of here. Do we need to send emails to Steve Jobs himself for someone to take notice that we're sick of something as simple as this being an issue. Shame on you Safari/Webkit.

[Knodi]

I have stopped using Safari just before of this bug.

It is such a major bug too it FREEZES the whole browser some time for MINUTES!

[Alexei Yudin]

I totally agree with Knodi! I love Safari more than Steve Jobs does, but this bug made me switch to Firefox. I still check out Safari once in a while wondering if they fixed it.

I've noticed this bug a long time ago when I started reading LJ community where gifs are used a lot. I sent a bunch of bug reports and wrote about this problem in Apple forums thread (http://discussions.apple.com/thread.jspa?messageID=9601292). Now I'm here, I don't what else to do. A letter to Steve actually seems like a good idea. LOL

[Alexei Yudin]

Upgraded to Snow Leopard a couple of days ago and I gotta say, they finally fixed this bug. Still, we have to draw attention to this problem, because there are and there will be a lot of Leopard users out there, even after SL release.

[Peter Kasting]

*** Bug 24710 has been marked as a duplicate of this bug. ***

[Peter Kasting]

*** Bug 21589 has been marked as a duplicate of this bug. ***

[Shamil Kerimov]

several reports indicate that SL doesn't fix this bug, but only reduces its impact. please investigate further! it's still very, very annoying. why Firefox does play GIF animation smoothly and WebKit doesn't? this is ridiculous.

[Acidic Rebirth]

No, this issue is not fixed in Snow Leopard. To this very day, GIF images continue to rape Safari, the CPU, and load at ass slow speeds whereas Firefox continues to load them perfectly. I'm beginning to hate Apple. I'll stick with Firefox... again.

[Mark Rowe (bdash)]

Please file new bug reports with the URLs of GIFs where you’re seeing problems.

[Kevin M. Dean]

Just did a quick google search for large animated gifs and here's a page that could be useful.

http://forums.gametrailers.com/thread/animated-gif-thread/883951?page=1

While performance is not near as bad as it used to be, my dual 2.7 GHz G5 running Leopard definitely get's laggy scrolling up and down this page and at times gets the spinning color wheel. It never can scroll up and down smoothly. With Firefox however, after it initialy has a heavy cpu load when hitting the page, it reduces to about 40-60% as I scroll up and down the page without issue.

[Kevin M. Dean]

Note the original url provided at the beginning still exists and still loads slowly and eventually causes the spinning wheel with 99% Safari cpu for me. In case it goes away, the file appears to redirect to: http://static2.aintitcool.com/files/HoD2.gif

[Mark Rowe (bdash)]

Leopard isn’t particularly interesting.  GIF decoding was substantially improved in SnowLeopard.  The image at <http://static2.aintitcool.com/files/HoD2.gif> loads and plays with very minimal CPU usage on SnowLeopard.  Given that the original reported issue was addressed, I’m going to close this bug out.

People should file new bug reports about specific images that use excessive CPU on SnowLeopard or Windows.

[Kevin M. Dean]

(In reply to comment #26)
> Leopard isn’t particularly interesting.  GIF decoding was substantially improved in SnowLeopard.  The image at <http://static2.aintitcool.com/files/HoD2.gif> loads and plays with very minimal CPU usage on SnowLeopard.  Given that the original reported issue was addressed, I’m going to close this bug out.
> 

Gee, thanks for nothing... considering the original reported issue was from me and for Leopard and still exists even if you guys have moved on and don't consider it interesting. When can I expect my complimentary brand new intel-based computer with Snow Leopard on it?

[Mark Rowe (bdash)]

The issue you reported was determined to be an issue in the ImageIO GIF decoder.  As such it was addressed in the ImageIO GIF decoder.  We can’t magically fix an issue in an underlying OS library in WebKit.  In many cases we can work around the problem, but this isn’t one of them.

[Kevin M. Dean]

Wasn't it odd that the preformance broke between nightly releases though and not with a Safari or system update. Maybe since the image decoder is broken under Leopard, it should just revert to the previous method used for Leopard users. I guess if it wasn't fixed when it was originally reported years ago and before Snow Leopard was released I shouldn't expect anything now. One was just expect the platforms that Safari is released on should still be supported when it comes to outstanding issues.

[Mark Rowe (bdash)]

It’s not odd in the slightest.  Animated GIFs were animating too slowly prior to the r37612.  After that revision they animate at the correct rate.  Animating faster naturally leads to needing to decode at a more rapid rate which in turn uses more CPU.

[Peter Kasting]

There is one way in which this could conceivably be fixed for Leopard or earlier, which is to switch from using ImageIO for decoding GIFs to using code in the WebKit tree.  This would decouple the Safari GIF decode performance from the OS-provided libraries.

However, making this switch would require that performance and capabilities (e.g. color profile support) not regress, and the Safari team consider it a net win.  In the past that has not been the case.  Recently the Chrome team has made this switch on the Mac, in the process adding some color profile support to the decoders in the WebKit tree.  I am not sure whether it's the case yet that the Safari team could consider a similar move.

Mark, if you'd be willing to consider this again, contact me any time this next week; I'll try and get more info from Adam Barth about the current state of the decoders.

This bug should remain RESOLVED FIXED in any case, however, since it covers the problems in ImageIO that have been fixed; if we do go ahead with the above, we'd do it under a new bug.