iOS Safari seems to render it with no performance issues. Interestingly, it can’t seem to decide whether the background is black or green—it’s different each time I load the gif.
Browsers and other players will generally be fine, as they render the image progressively. However, editors /processing tools which attempt to load it as a series of frames or a video will usually break, as memory consumption explodes, unless they have a smart disk buffer system to handle it.
I wouldn't be surprised if some poorly implemented players were built on top of abstraction layers that end up flattening the whole thing too and also break, but browsers at least generally do it right.
Why not cap animated gifs at a maximum duration or file size? GIFs original use cases are already served by formats better suited to the modern era.
Their continued popularity seems due mostly to their historical auto play behavior. One that apps are so reluctant to disrupt we're filling landfills with electronic waste to keep up with ever larger and longer meme animations.
Actually software which edits animated GIFs doesn't have to crash per se, it's all about how smartly it's implemented, and because GIF editing isn't exactly a sprawling industry, most apps tend to be, well, not that smart, and so edge cases can get them.
Formats don't have to be fully implemented to their original spec for all time. If it's not serving us well today then we can change how our software uses it.
If the goal is to stop obscene memory and bandwidth bloat then changing the default to a click-to-play/load would be better. My thinking is too change the incentives so producers aren't exploiting an old format to force autoplay at the expense of wasted resources and user control.
i'm pretty surprised apng hasn't really displaced gif, at least not completely. a lot of people don't seem to even be aware pngs are animatable these days
Lack of awareness is the main issue by far, but momentum is another. gifs are doing the job and people already have tools they are used to, so there needs to be some compelling reason to switch. For many small animated icons the file-size difference isn't going to be massive and an 8-bit pallet is usually sufficient, and once you start wanting larger animations and full-colour people have already moved to video codecs instead or for non-video-like animations maybe even manipulating SVG. There are no doubt sweet spots where APNG is ideal, or even the only really good option, though I can't think of any that would be common (wanting an animation with an alpha-channel rather than gif's all-or-nothing, maybe).
Another matter is compatibility. IE11 is a no-go which even after the recent announcement will kill APNG for some. And while Edge now supports it this has only been the case since the switch to being Chromium based (so the beginning of last year).
I think this is because video codecs superseded everything else. An MP4 file is going to be roughly the same size as an apng, while enjoying hardware acceleration on a lot of devices out there.
There's still the weird niche of lossless compression where apng or webp would be preferred.
20 years ago the case was stronger but video codecs have both soaked up the performance wins and do not expose new security exposure.
Based on APNG and JPEG 2000, the only question I have for new formats is how they plan to get browser support. It’s a hard path to relevance unless you have a good answer for that (even if it’s, say, a WASM fallback).
a wasm fallback for a format is a perverse yet interesting idea. Seems like the main hurdle for new formats (at least patent unencumbered ones) is safari. webp finally made it in, av1, there's a pull request but we'll see what happens
We just need an actual replacement that has the same behaviours and actually works everywhere, as gif does. Videos are not a replacement, and other image formats don't work everywhere
H.264 level 4.0 seems to have similar behaviors and works on a very wide variety of platforms in my experience.
Chrome, Firefox, Edge, Android, and iOS. That covers most of what we want, right? It fails on say... a 2009 era netbook or Android Gingerbread, but we gotta draw the line somewhere.
Even if you do care about Android Gingerbread: H264 3.0 Baseline profile IIRC worked on that (though its been a decade, so maybe I'm getting version numbers mixed up...). Going back to H.264 3.0 Baseline would reduce your compression-efficiency (more distortion / noise at same filesize, or larger filesize for same levels of distortion), but greatly improve your compatibility with decade-old devices if you cared.
Even H.264 3.0 Baseline is a far superior format compared to GIF though.
-------------
Lol audio is a mess though. But video-only is actually way better than most people expect.
Most of gfycat's traffic these days is .mp4 files that pretend to be gifs. Even if you upload a gif, its converted into .mp4 because its a far more efficient transmission codec.
I'm sure there's some javascript / backend logic that handles some corner cases. But... yeah. A lot of self-looping .mp4 stuff seems to be solved. The <video> tag has been getting more and more consistent these days.
I just do some hobby stuff though. I only test on the stuff close to me (chrome, edge, firefox, my phone). So I can't say too much about reliability on older / more obscure platforms.
Twitter does the same, and I (along with other people) hate it. I mean... nice that it saves data, but I can't save it. To download an image is SO simple, but have to rely on 3rd party services to convert the video back to gif if I want to post it as gif on twitter later, or send as gif on whatsapp.
I know enough about the debugging terminals in Chrome and Firefox to just "save-as" the .mp4 file itself. So I personally haven't had any problems with saving or sharing .mp4s. (Most commonly: grabbing some animated .mp4 meme and copy/pasting it into Discord)
But yes: its weird that Chrome / Firefox don't have easy-to-use "save as" buttons on .mp4s. But just grab the .mp4 and share the .mp4 on whatever services you use.
Increasingly, it seems like .mp4 is becoming the new gif. Its not quite as user friendly yet, but there's all sorts of advantages compared to .gif.
> I know enough about the debugging terminals in Chrome and Firefox to just "save-as" the .mp4 file itself.
Right, so this just don't work for like 90% of the population, or when you are on mobile, right?
Edit: what I mentioned about saving the mp4 and having problem later is: if I save the video and then try to re-share it on Twitter, it will be shared as a video, and not as a gif - or at least that was the case last time I tried
Can I just upload a H.264 level 4.0 video anywhere where an image is allowed and it will be displayed as an image? Will it be displayed as an image in any forum, chat/messenger platform? Can I use it as my avatar in places that allows for gif avatars, like Mastodon?
Hmm, I'm thinking about the Web-browser level (Chrome / Edge / Firefox) instead of say, web-application layer (ie: PHPbb vs XenForo).
The web browsers seems to have significantly improved compatibility of <video> in recent years, and even had decent compatibility 10 years ago (if you use Baseline profile H.264 3.0 videos and Javascript to smooth over some edges).
I've seen this debate happening for so many years, and people will not stop using gifs until other solution works exactly as a gif for the end user. APNG or WEBP would be a better solution, as they are images in the end.
You say they had decent compatibility 10 years ago, but no. At least a couple years ago you still needed many fallbacks and it was a hassle to guarantee the video would show properly. Not to say that you wouldn't be able to share it as image to tumblr/pinterest for example.
One interesting aspect of WebP support (or lack thereof) is that it doesn't work in Slack or Discord, even when those are running in a supported browser. I think things like this are inhibiting adoption of newer formats.
That is a way better solution, although APNG didn't help much for my test in terms of data, a 1.8mb gif was converted to a 1.5mb apng, not even worth my time to google gif to apng converter.
Webp worked well though, resulting in a 300kb webp. Might try to start using it
It sometimes feel like it is a bonus today, if apps bother to clean up their memory at runtime, so maybe that's why parent poster thought it is a good and special thing, that the OS free's the memory of an ended processes.
Btw. many people don't seem to know, that also in languages with a garbage collector like Javascript, you can create awesome memory leaks. And I would bet, most websites actually do: it only works, like it works, because websites are closed regulary. And because RAM is every increasing. But browse with a older smartphone and you hit the RAM limit very quickly.
I have 32GB of RAM and it sits unused most of the time. Right now I am at 4GB/32GB. It simply isn't a significant source of memory consumption. Open Atom and you can easily get to 500MB for a single application, which is completely wasteful. That browser can run dozens of apps in 4GB.
On the other hand, my browser (Firefox) keeps overflow through 8GB ram few times a day. Sometimes I wish people programmed like we had 512megs in a luxury machines.
I also have 32 GB RAM and right now am at 25 GB + 2.4 GB in swap. I'm at around 20 GB most of the time but always have at least 3 Firefox tabs open. Sometimes a buggy process (looking at you, Apple…) decides to go haywire and use 30-60 GB of virtual memory. I don't even notice that until I have a look into the activity monitor. Handling RAM spikes seems to be no issue at least on macOS.
In ff and chrome tabs are processes. So aside from resources allocated on behalf of that process by other processes not being cleaned up, the OS will cleanup all the memory that tab told the OS to allocated when closed.
Firefox user here, plenty of tabs, Win10 as OS. 3.7 GB before opening the GIF in new tab, 3.8 after opening, 3.7 after closing. Reopening and closing it several times in a row yields the same results, consistently. At least for my setup (Win10 heavily crippled to my own liking) closing tab == closing app in terms of memory gained back.
It would be fair for a browser to assume that if you’ve just visited one page that you might return soon, and so keep assets in cache for a little while.
A process which doesn't exist cannot hold memory. But the OS can certainly chose to defer the erasure as long as there's no better use for that memory. This is often done to speed up the performance of processes which are frequently quit/stopped and reopened/started.
> A process which doesn't exist cannot hold memory
Not quite. Some leaks are across processes. If your process talk to a local daemon and cause it to hold memory then quitting the client process wont necessarily free it. In a similar way, some application are multi-process and keep some background process active even when you quit to "start faster next time" (of act as spywares). This includes some infamous things like Apple updater that came with iTunes on Windows. It's also possible to cause SHM enabled caches to leak quite easily. Finally, the kernel caches as much as it can (file system content, libraries, etc) in case it is reused. That caching can push "real process memory" into the swap.
So quitting a process does not always restore the total amount of available memory.
This sort of thing is a known historical attack surface. At one point not too long ago, people were attacking Discord's browser and desktop clients by embedding massive carefully-authored GIF files to exploit the fact that Chromium (thus, Chrome and Electron) decodes GIFs partially or wholly in advance, so the GIF would quickly consume all memory available to the tab/app and either crash it or bog down the system.
I think Discord implemented some measures to guard against those files and Chromium was patched to mitigate this (which is why Edge and Vivaldi are fine), so it's not surprising that something like Safari might struggle with Evil GIFs under certain circumstances as well.
My GIMP process reached 278MB (93MB of which was shared). According to the Dashboard tab, 60MB of that was cache, including layer thumbnails and mipmaps. It's definitely not inflating the memory footprint more than expected. It's hard to count the total pixels, since every frame has different dimensions.
Ristretto: 48.8MB. EOG: 51.3MB. ImageMagick: 169MB. Firefox: 305.1MB. Vivaldi: 185.2MB. Edge: 196.5MB. GIMP: 244.8MB.
OS memory usage remained relatively flat once app exited. xUbuntu 20.04.