Hacker News new | ask | show | jobs
by dTal 4468 days ago
I agree that for most uses of GIF nowadays, a video codec would be superior, but better in every way? What about decoder overhead? For certain sizes of GIF, the combination of GIF + GIF "codec" (a trivial XOR) will consume less memory than, say, h264 + h264 codec - in some cases far less. A modern video codec is not at all trivial, and also is optimised for filesize, not CPU load.
1 comments

> For certain sizes of GIF, the combination of GIF + GIF "codec" (a trivial XOR) will consume less memory than, say, h264 + h264 codec - in some cases far less.

Memory, maybe. But CPU?

I keep this snippet[1] at hand at all times, because pages with multiple animated GIFs peg my CPU and make my fan spin up for as long as they're open (even when they're in hidden tabs! even when the GIFs are scrolled off the screen!) This doesn't happen with <video> elements.

I think the problem is that web browsers never bothered to move GIF decoding/rendering/compositing to the GPU. It's especially bad if a GIF is animating while it has CSS image-scaling applied to it, which leads me to believe that--since the GIF "codec" must be re-applied on each frame--the browser doesn't cache the decoded frames, and thus can't cache the scaled decoded frames.

[1] https://gist.github.com/tsutsu/9289a7e52351a3c947cf