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.
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.
It at least causes ImageMagick to explode, and generally anything that tries to flatten out the GIF into full canvas-sized frames.
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.
We should drop gif support.
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.
There are a lot of corners of the internet which just haven’t been touched in a decade. Are you going to break all of them? For what purpose?
Rather that renderers / apps would put a pause on downloading and processing very large (say 1MB+) or very long animations (100+ frames).
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).
There's still the weird niche of lossless compression where apng or webp would be preferred.
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).
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
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.
edit: grammar
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).
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.
That has always Just Worked with GIFs, but the last time I checked (a couple of years ago) it basically never worked with any “proper” video format.
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.
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.
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
If you are posting a gif on a comments section of a website, or uploading to tumblr, for example, you don't have this control
WebP support (including animation) was added to the most recent major version of Safari, meaning WebP has similarly widespread support.
Webp worked well though, resulting in a 300kb webp. Might try to start using it
edit: nevermind, webp doesn't work on whatsapp.
That’s part graceful and part a security hole. It means you can hide any image you want if moderation tools don’t show past the first frame.
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.
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.
But that could pile up quickly, so I am not sure if and how it is done in the various browsers.
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.