> It may take longer to load, but I can have 100+ GIFs playing at once with no impact to my CPU.

I don't know what you're talking about really... I was just using Google Slides today and both Firefox and Chrome went to 250% CPU usage, only because there was one slide with a 5 seconds full screen recording GIF. I begged to the person who added it to turn that to a video.

Yep, browsing pages laden with too many GIFs is my favorite way to have a hot laptop that sounds like it's getting ready to lift off and get my low battery warning to pop up.

In my experience that's a google slides problem, not a gif problem.

Google problem not gif problem, sites like knowyourmeme embed 10 gifs in a page routinely with no issues(apart from the loading time)

> The most important part of GIFs for me is that they behave like images in browsers. They are always auto-playing with no concept of play and pause. You can drag and drop them from a browser to your desktop to save them. You can save an entire page and have all the image files save with it. I've never had this work for webm or other video formats.

The saving bit is the only part which doesn't work right with videos AFAIK. Sound-less (/muted) videos can autoplay and loop, and there's no controls unless you ask for them (via the `controls` attribute) or bring your own.

The examples in the article (the scenes are videos) autoplay, loop and don't have control in either Firefox or Safari.

I think the saving part is a big deal.

There are related problems like embedding. If you upload a video to Slack, say, you can’t control whether it autoplays or loops. If you upload a GIF it just works.

I understand that they can be made to autoplay with no controls, but I don't even want the possibility of them being paused. This way the format has no choice but to behave as expected across everything.

> I understand that they can be made to autoplay with no controls, but I don't even want the possibility of them being paused.

Your opinions are just that, and usually overridable by the client. The client could even strip your media entirely.

And gifs are pausable (used to be ESC though apparently you now need extensions).

> This way the format has no choice but to behave as expected across everything.

I've got bad news for you: once it reaches the client you're not in control anymore, you can only suggest behaviour.

I don't see why we can't use the IMG tag for video and the VIDEO tag for images. They should be unified, with all the same media formats supported.

IMG would autoplay, would not have sound, would loop, and would not have controls.

VIDEO would be the opposite. For something like a plain JPG or PNG file, it just shows the one frame. Animated GIF files would of course benefit from the controls.

The same should go for unification of the VIDEO and AUDIO tags. Play an audio file as video, and you get a black screen with sound. Play a video file as audio, and you just hear the sound.

Agree. Safari has already made moves for this[1], but Chrome seems to be resistant[2].

[1] https://calendar.perfplanet.com/2017/animated-gif-without-th... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=791658

> IMG would autoplay, would not have sound, would loop, and would not have controls.

Why do you hate my phone battery so much?

They don't though. At similar quality and framerate, a video is much smaller than a GIF (so the radios can be shut down faster) and requires less power to playback (because it's offloaded to the hardware acceleration instead of being implemented entirely on the CPU).

Your average smartphone can play 1080p video without breaking a sweat, not so with 1080p gifs. Hell, a laptop will have permanent high-CPU usage on 1080p gifs, as a video it's background noise (https://www.reddit.com/r/osx/comments/43rrf0/pixel_art_gif_a...)

> I don't even want the possibility of them being paused

That's downright hostile to the end user…

https://www.w3.org/TR/UNDERSTANDING-WCAG20/time-limits-pause...

A behavior being unchanged for 30 years is hardly user hostile. It's reliable and trustworthy. Like a good tool should be.

You used to be able to press the escape button to stop GIFs on the page. It's not unchanged for 30 years.

Browsers have changed, a lot, in sad and unfortunate ways like you mention here, but the gif format is pretty stable.

Any application that doesn't allow me to stop something from being annoying, will be stopped from being annoying by being uninstalled.

If browsers made it such that I couldn't not stop .gif animations (or playing video, or...), I would trash that browser.

Bluntly, you do not get to control my computer.

The point is that they are more images than videos. They have no possible way to contain sounds so the annoyingness is limited to having unwanted images in your browser. You can tell your browser to block a particular still image. You can do the same thing to block a GIF. You don't need a pause/play feature on a 2-5 second sequence.

No, the point is control. You have no idea what I need.

Most people require much less.

What is your current solution to autoplaying, unpausable gifs?

Case by case basis ublock origin and permanently remove the gif from showing up in my browser ever again.

If that 2-5 second animated sequence is smack dab in the middle of an article I'm trying to read, because the author is trying to be "cool" and "in with the internets" by including some popular animated meme macro? You bet your bellybutton that I need to be able to stop it from distracting my eyes from the text.

Human sight has evolved to be attracted to movement.

There's nothing about allowing play/pause that prevents videos from behaving exactly like gifs. I've seen browsers with play/pause options for gifs, even.

The stop button used to stop all gifs on a page in firefox and internet explorer. Not sure if that was a bug or a feature though, since the stop button was generally not available when page load finished.

(Maybe I remembered wrong, someone else mentioned here that it was ESC, not stop)

At least on Firefox, it was indeed stop. I believe it still works too, even though nowadays they hide the button, if you expose the functionality through an addon.

Can you tell me of one, please? I'd like to check their implementation, most play/pausable gifs I see are only converted webms.

> [...]but I can have 100+ GIFs playing at once with no impact to my CPU.

That's... not entirely accurate. What do you think is rendering all those gifs to screen?

No "major" impact to the CPU. As insignificant as displaying however many frames exist in the gif as still frame jpegs at the same time.

That's still not accurate. Load up 20-30 gifs on a page and I can pretty much guarantee you'll see your browser saturate a core.

Challenge accepted.

https://www.hampsterdance.com/classics/originaldance.htm

Just did it on my 2011 MacBook Air. Pushes all four cores up... about 15%.

> Just did it on my 2011 MacBook Air. Pushes all four cores up... about 15%.

15% of 4 cores ~ 60% single core capacity. That's distinct from saturating a core both qualitatively and quantitatively, which means the prediction is not a bullseye... but it's on the order of magnitude in impact, which means they're not entirely wrong.

True, but it's an eight-year-old computer. And it wasn't exactly a computing powerhouse when it was released.

Try this, http://www.voots.name/

That one actually did better.

Two cores went up 20%. The other two didn't budge. Go figure.

There we go. Try that with video formats.

Giphy manages to consume a much larger fraction of my modern desktop's CPU. I think it may have something to do with the small size and multiple copies of the gifs on the page you chose.

For best results, use a Slack channel, or a forum reply page with an array of animated smileys.

To complain about GIF usage saturating your CPU when running an Electron app is to be penny-wise and pound-foolish.

Slack doesn't exactly have the most efficiently implemented front-end interface.

Ah, yes, I didn't realize that Slack's platform reimplemented the whole graphics-formats-rendering stack. I naively thought that Electron and Slack inherited that from Chromium, but guess stupid me is way behind the times in this technicky stuff. Of course it's all in Javascript now, what was I thinking!

Do things change if each gif is different?

Try again using a gallery page on a site like giphy which is going to be more representative of the use case op was talking about.

edit: such as https://giphy.com/sports/2019-stanley-cup-playoffs which seems to be entirely gifs if you view page resources in the debugger.

I don't believe these are actually gifs here. Similar to sites like imgur or twitter they convert it to something else to host for other people. Probably to keep bandwidth down. You can get to the actual gif, but you have to dig for it.

Most animated images on giphy are vp8 videos.

The other seven cores that are not being identified as "my CPU".

Strong agree. Just as HEIF is a video format adapted to be a still image format, the GIF successor should fit in an img tag and be guaranteed not to have sound. Perhaps it could be a different sort of container with the same compressed bitstreams.

There is an AV1 "image" format too, which supports "image sequences" but not, oddly, animation.

GIFs, in pre-AV1 terms, are simply a video with 100% lossless I-frames and autoloop enabled.

You can express the “lossless frames” aspect of GIFs today in existing video ways supported by MJPEG, H.264, H.265, or AV1 today.

AV1 image sequences are meant for sharing an album of stills, and are not a convenient shortcut for this.

Feeding a sequence of frames into `aomenc --lossless=1` should, assuming everything else is working correctly.

I believe looping is not currently a property that you can readily set at the codec level, which is perhaps the most critical missing feature of AGIF when considering codecs.

Perhaps focusing on the “loop” flag’s presence/absence and whether it’s honored by browsers would most usefully serve the post-GIF world?

Would looping not make more sense at a container level, not a codec level?

Far more sense, but containers are a disaster zone in video. Is it av1 in webm, mp4,fragmented mp4/cmaf, or ts? Where does the flag go in each?

And for bonus disaster problems:

Should AGIF continue to autoplay when in more efficient other formats it may not?

Animated gifs are compressed, and do require decoding. Hell, so do non-animated gifs. Since animation was added in the '90s, GIF is basically just a really inefficient (but extremely well-supported) video format.

I agree that there won't be wide adoption of AV1s until it can transparently be interacted with just like gifs are now.

That is true. I suppose even jpegs are compressed and require decoding. I'm pretty sure it is orders of magnitude quicker than video decoding though. I can have 500 gifs playing at once just fine, but if I had 500 equivalently sized webm h264 videos playing my computer would have a stroke.

GIF is super slow to decode, more so than any modern video format!

It doesn't seem like it mostly because browsers (slowly) decode GIF as they (slowly) download it, and cache all uncompressed frames in RAM. They don't do the same for <video> tag, because they assume it's only for high-res, non-looping video.

• GIF data is huge. 15x-20x times larger for the same dimensions & quality than normal video codecs, and sheer amount of bytes to chew through eclipses any savings from it being slightly simpler.

• GIF's compression doesn't support any parallelism. Frames have to be processed bit by bit, frame after frame. Your multi-core CPU can use only a fraction of its speed when decoding. OTOH modern formats support parallelism on all levels - frames, tiles within frames, blocks, transforms. Modern CPUs can process these very effectively.

• In modern systems RAM is ridiculously slow relative to computing power available on the CPU locally. However, GIF's LZW is based on lookups in a dynamic dictionary, so not only you have just one CPU core process it, the core mostly spends time chasing pointers.

• There's no hardware acceleration for GIF. For newer codecs it's quite common and very power-efficient.

There's no technical reason (other than legacy code) stopping browser vendors from treating AV1 just like GIF, with all looping <img> glory. In fact, Safari already supports H.264 in <img>! It's faster in every way.

It doesn't make sense to use GIF for lengthy or large resolutions. For a 16x16 pixel image with 5 frames though...

Note that AV1 has palette-based blocks, so it's even better suited for GIF-like images than GIF.

GIFs are quite expensive to decode, it's all in software and while the encoding is fairly simple the amount of data is huge (especially for high-quality gif in which each frame will be present in full). Gif playback is commonly CPU-bound on the more complex examples.

I can't find it quickly now, but I recall some browser vendor (perhaps Apple?) discussing support for videos in <img> tags, but having them behave like gifs as you describe. Not sure what became of that.

Yep. You can include them in any forum or comment post that supports [ img ] tags. That's one reason why it's so infuriating that Google Image search now returns videos along with images because video-gif sites like Giphy look just like actual gifs in the results but you can't embed them.

>>I can have 100+ GIFs playing at onee with no impact to my CPU It wasn't that long ago that a page full of emoticons (animated gifs) would bring a computer to it's knees (when posting on vbulletin or something)

I had to turn off GIFs and animated emoticons in Slack because it was making my fan spin up and consuming a significant amount of CPU.

That's because of Slack, not because of .gif files.

>They are always auto-playing with no concept of play and pause.

Which is why I can't wait for GIFs to die.

> It may take longer to load, but I can have 100+ GIFs playing at once with no impact to my CPU.

I remember this myth, saying that the first moon landing required as much computing power (command central, ship etc.) as rendering a GIF. No mention about the resolution, frame speed and so on, though. Hence I think it's a myth. On the other hand you could probably tune those parameters enough to actually make it a true statement ...

GIF is not very CPU-intensive, but I definitely remember systems slow enough that JPEGs loaded at visible speed over a couple of seconds. I also had a Libretto 30 that could play MP3s, but only with the Fraunhofer decoder and not the Winamp one which couldn't quite keep up with realtime.