Animated GIFs often burn huge amounts of CPU on my machine. A page full of GIFs can bring a modern computer to its knees. (This is one reason many image sharing sites convert uploated GIFs to proper video files, mp4 or webm or whatever.)

I’ve never quite understood why implementations of GIF viewers in web browsers were so bad. In many cases it seems like they could cache every frame in GPU memory somewhere and very cheaply loop them. Caveat: I haven’t studied this in any detail, and am not an expert on image/video formats.

While the browser vendors haven't done this - some of the image hosting sites (who are far more directly affected) have.

Imgur automatically converts larger GIF files to "GIFV" (WebM or MP4). The size difference is nuts: their example is a 50MB gif being reduced to 3.5MB

Their announcement post about it: http://blog.imgur.com/2014/10/09/introducing-gifv/

It's such a mess though.

You have gif with all its quality loss (256 colors and etc.), and then to make matters worse it's getting shoved through webm/mp4 encoding.

And then there's everyone from Imgur to Twitter missing the point of why gif is even a thing. Because it is simple. Because gif is treated as an image and not a video format. Because you can right click it, and save it for later use. Can't do that with "gifv" (seriously, I had to use curl just to get the video file from Imgur), and definitely can't do that with Twitter.

Neither webm nor mp4 can kill gif yet - mp4 is a patent mess, and webm comes closer (4chan for example has a quite big SFW community of people trading videos), but there are issues with Apple refusing to support it, and lack of hardware support.

A small note on a common misconception - the mp4 format is not something that is patented - that's h264.

Broadly speaking video files are first a container (e.g. mp4, avi, mkv, ts, etc). A container is sort of like a zip file. It groups together metadata about the file as well as the audio, video and possibly subtitle streams. In fact if you view an mp4 file at this level it reads like binary XML with 4 byte tag names.

The video streams are encoded using a video codec - e.g. h264, h265 (HEVC), vp8, vp9, ProRes and many others. Audio codecs are similarly varied - e.g. AAC, mp3, vorbis, theora and others. These are the parts of the file that can be patent encumbered.

In theory there is nothing stopping you from making an mp4 with vp8 video and vorbis audio. You can even ask ffmpeg to do it - it will happily oblige (and ffplay will play it). However the reality is that most non-smart video players will freak out at this kind of file.

Most simple players will expect mp4 to contain h264/AAC. This reality is starting to break with h265 encoded video in an mp4 container. Hopefully some of these assumptions will disappear over time. I believe mkv is currently the only reasonably popular container format that can usually play whatever audio/video is inside (mostly because only "advanced" players can even read it).

To add some confusion WebM is actually a hybrid. WebM is a more restricted mkv container with a VP8 OR VP9 video codec and vorbis or opus audio codec.

>Can't do that with "gifv" (seriously, I had to use curl just to get the video file from Imgur), and definitely can't do that with Twitter.

youtube-dl works with basically everything that matters, including imgur gifv and twitter videos.

  youtube-dl https://twitter.com/Footballogue/status/841905302438043648

  youtube-dl http://i.imgur.com/te50Z9W.gifv

youtube-dl is the best thing since sliced bread.

thanks to youtube-dl it is simple to download videos in a nice format instead of as gif.

gif as a format has served it's purpose. let gif die.

That's not user-friendly at all.

There are untold number of GUI and web wrappers around youtube-dl.

With imgur, you can just right-click and hit `Save video as...` in both Chrome/Firefox (even without manually adding their ".gifv" extension)

Twitter though, doesn't seem possible

Try to save a webm if it serves you an mp4, though. Maybe they changed it lately, but I just could not figure it out - .webm and .mp4 both just silently redirected to .gifv last I tried.

Saving a video off imgur works about half the time in firefox, based on ???. There's a bug for it but it hasn't gotten much attention. It's a problem of imgur playing games with headers, embedding a video inside a web page and using the exact same URL for each. I haven't had any issues in chrome.

Twitter's just putting dumb empty divs over the content. And they make it impossible to get the source gif even in cases where the video version is larger and lower quality. Thanks twitter.

They also do YouTube-tier blob fuckery, I believe.

> Can't do that with "gifv" (seriously, I had to use curl just to get the video file from Imgur), and definitely can't do that with Twitter.

That’s just because their implementations are bad. Browsers have a “Save” context menu entry for videos by default.

What are you talking about?

If people upload a video, then the gifv has more or less full fidelity.

If you right click a video, you can download it. See http://imgur.com/eOsqgv3

Some sites go to quite some length to ensure that users cannot download videos easily (I believe youtube has some javascript that assembles a lot of different video files while playing to ensure you can't get a direct link to the video) but you can go to similar length to protect normal images.

I'd say anything on twitter is a bloated mess.

The really silly thing about imgur is that they won't let me upload a 10mb mp4, but they'll let me convert it to a 90mb gif and upload that.

There are certainly many cases where using video instead of GIF makes much more sense. But if you're talking about continuous animation of 10+ elements, then I'm not sure video is a good idea. We recently optimized electricitymap.org to use GIFs instead of CSS/SVG animations, reducing CPU usage between 50-95 percentage points (depending on setup). In our case, we were animating ~70 arrows causing 100% CPU on many machines, including my own beefed up MBPr from late 2013.

Looks great indeed, there is also the option to dynamically render the SVG animation to a sprited or multiple canvas once, and avoid to reevaluate and render the SVG for all instances on every frame.

There is no reason clients can't encode a GIF or APNG to H.264, cache that, then use the hardware video decoder on the GPU to render it. Whether that would be a win for performance or battery life probably depends on the exact hardware and how many of these things are displayed at the same time.

Using the optimized video code paths for GIF was discussed by the Mozilla graphics team several times. Basically the conclusion is that it's a lot of work when there's a perfectly good alternative which is using a video element. Effort that can be better spent elsewhere.

That's a shame, because there is a hell of a lot of legacy content out there that's never going to get converted.

maybe let Mozilla know that it would be very helpful to their non-profit cause if they spent some time in rust making this work better.

they spend a lot of time adding new milestones, but this is one which could improve the quality of the web.

or they could design an extension which converts gifs to pdfs and we could continue to use their software for what it is:

zero day gateway with attached subscribers to a non profit software engine company which spends a bunch of time doing what they feel could make their impact last any longer than it already has

at least then the pdf would open in chrome :)

translucency

Structure of animated GIFs is odd - you pretty much have to read entire file to animate it correctly; hence the inefficiencies.

That is true, but after being rendered once it could be cached locally in some other way if that is believed lead to better performance.

Why do you say that? All of the metadata is at the beginning, followed by sequential frames.

The frame data is incomplete with no keyframes - if you want to do a fairly typical memory conservation technique where after user switched away from the browser tab, you pause a GIF, unload it from memory, and then need to reload it from the same frame when user switched back - you will need to replay entire GIF to that frame.

At least for pixel graphics with transparency converting gif to apng would be a far better choice than gif to h.264 or vp9.

The thing is that you want 4:4:4 (no chroma subsampling) + alpha + lossless for pixel graphics. While some video standards support that in theory browsers often don't support those advanced profiles.

I was surprised how well ProRes 4444 worked-out in practice for Windows/Mac/other(ffmpeg). The only downside was enormous size.

https://en.wikipedia.org/wiki/Apple_ProRes#ProRes_4444_and_P...

ffmpeg is not the issue here, it supports several 444/alpha/lossless codecs quite well, proes is not special in that regard.

Browsers only expose a small subset of codecs that ffmpeg supports. gif and apng are now the most compatible format in browsers for this kind of content.

FourCC of ap4x 'just worked' on IE (I might have installed QuickTime codecs), Safari, and gstreamer with Firefox - it just played in the window (though I did not test alpha channel). I was surprised too ;)

I've noticed that gifs are made into videos too. I wonder if apng's will be efficient. I would think a small animated image like a .gif would be more optimized than a full on video file but I guess not.

Once you understand how videos are encoded, it's pretty obvious why gif (and apng) are not and will never be as small as videos. Videos use temporal data. You have one key frame (where the whole image is stored) and the following frames are encoded as delta (difference) from the previous frame. So a still video could basically be the size of a single image.

Animated images aren't that smart, they're just a bunch of images, so you're storing every single frame.

It's not quite that stark. You can have the non changing background solely in the first frame, and have subsequent frames (smaller frames even, placed at offsets) composed solely of "sprite like" things that overlay. And there are tools like imagemagick​ that can optimize existing animated gifs in that way. It is crude, but it's more than just a plain sequence of unrelated full size frames .

> Animated images aren't that smart, they're just a bunch of images, so you're storing every single frame.

GIF89a has a sort of limited delta encoding via the "do not dispose" option. If you write a frame with "do not dispose" and then write a frame with some transparent pixels, the transparent pixels will retain the colors from the previous frame.

It's rather primitive but it's better than nothing.

Are there tools that take existing normal gifs and convert it to make use of that? Because manually creating such gifs are generally a huge pain.

Use gifsicle. It's excellent and very fast, I don't think there's anything that produces smaller gifs than it. [0]

You can also use ImageMagick to produce optimised gifs (it has about 4 different options for that, eg -layers OptimizeTransparency). See [1]. But in my own tests, gifsicle always beats it (often by a huge margin) and is vastly faster. That ImageMagick page may be out of date. Also, Tumblr contracted the author of gifsicle, Dr. Eddie Kohler, to make some improvement for them, hopefully that made it back into gifsicle [2].

[0] https://www.lcdf.org/gifsicle/ [1] http://www.imagemagick.org/Usage/anim_opt/#compress_opt [2] https://engineering.tumblr.com/post/80003435120/who-doesnt-l...

I think most GIF optimizers would do it, although I haven't tried any. E.g. https://ezgif.com/optimize says they do it ("makes unchanged parts of the following frames transparent").

Disagreed, BPG (better portable graphics) is based on H265, but aimed at animated/nonanimated pictures. From my tests it runs really well.

If you have a hardware H.265 decoder, sure - I'd wager a GIF or APNG runs better in single-thread, CPU-only environments.

Kind of an old reply, but I should honestly test that- encoding on a CPU only environment compared to one with a GPU with specialized support takes around 4-5x more, but I didn't test decoding yet on a CPU only environment yet.

Doesn't this just mean that SVG implementations are poorly optimized, and don't make proper use of the GPU?

SVG is much more powerful than APNG and optimizing SVG for cases already handled by APNG is probably not a priority.

Updated graphics benchmarks, including SVG: http://browserbench.org/MotionMark/about.html

This is true, if you animate CSS properties that trigger reflows you can seriously harm battery usage.

I try to stick to only animating the transform property, which should perform better than a raster format, since it doesn't require any new data per frame

I had the same approach as this. But not all animations can be made using the transform property, and even if you avoid reflows you can still have a lot of CPU usage with simple animations. In our case, we were moving a gradient inside a div. You wouldn't think this uses a lot of CPU, but if you have enough of them, it becomes a problem - there is apparently a lot of CPU processing involved in re-rendering regardless of reflow. Using the translateZ(0) trick did not eliminate the issue.

In my experience, you really need to work with designers who are willing to consider the technical impacts of design choices within the browser. You need to be able to say, this animation style causes strangeness and performance impacts... are their other designs that don't have the same technical needs and still achieve our product goals? The coder needs to be willing to understand the design constraints and the designer needs to be willing to understand the code constraints and both people need to take joy in finding solutions that tick every box.

If you have a "throw the designs over the wall" workflow, CSS will never work, you have to go to iOS or Unity or something like that where you have minute control over every detail. On some level, this becomes an identity issue... are you Mercedes, or Apple, who will marshal incredible resources to control every detail of a production, or are you a Craigslist, or Bikini Kill, who will sacrifice any and every technical consideration to maintain laser focus on a singular goal.

Put another way, are you the conqueror who flattens an entire ecosystem to build your perfect palace, or a craftsperson who takes a small amount of material each day, and makes something beautiful within the constraints?