gifs blow

but are the most supported + interoperable filetype for animations with alpha

gifs (note: please make sure you’re pronouncing this in your head as hard-G gifs, i’m not some sort of soft-G savage) are supported everywhere, offer great features, and totally blow

since we’re aiming for animations that have transparency (technical term here is “alpha”) factored in, potential filetypes are limited, but not as limited as you might think… here’s the list we’ve tested:

.webp/.webm
- .webp for stills (but can actually have sequences of frames to comprise an animation)
- .webm for video
.heic/.hevc
.avif
.mov
.apng
Lottie animations
- open source project that SUPER efficiently converts vector/shape based animations into animation sequences
…. and .gif

for our purposes (“our purposes” means complex animations with non-drawn components):

.webm is by far the most efficient option here (from our testing, but correct me if i’m wrong nerds!) BUT, .webm doesn’t load on Safari mobile

Lottie is a no-go with heavy “non-shape” elements in our emotes

.webp with a sequence of images loads on all tested browsers, BUT loads insanely slowly on Safari (desktop + mobile). until the first loop of the sequence completes, it plays back at about 0.25x speed. thanks Apple

.avif and .apng are huge compared to the other options and are not available on browsers

.mov with alpha is barely supported anywhere (and are also huge)

.heic/.hevc is Apple proprietary, and although i typed this on my MacBook Pro and proof read it on my iPhone, that’s dumb AF

so now you might be asking, “but wait, whoomp! if gifs are supported everywhere, why do they blow?”

here’s a whoomp emote (most likely in its .webm form, see fun fact at end). it’s 800×600 resolution and has a frame rate of 30 frames per second. like all whoomp emotes, it’s five seconds long, so it has 150 frames total. here’s the filetype size weigh in:

.mp4 (no alpha): 3.3mb

.webm: 4.4mb

full quality .gif: 22.4mb

“whoomp optimized” .gif: 11.4mb

when we first set out to make whoomp emotes, we were running 60fps, 1600×1200 animations. gifs came out to >=150mb! so we dialed back resolution and frame rate to 30fps and 800×600 respectively, and file size came down roughly 87.5% (since there were 4x less pixels and 2x less frames). but >20mb files were still pretty far from ideal, so we honed in on optimal gif settings with 25fps and secret sauce settings to get the “optimized” result linked above

visually, it’s pretty hard to distinguish between the optimized vs. the full quality gif – you can most notice it on detailed gradients (like the shadow on the frame as it tilts). but it’s undeniable that both gifs looks like TRASH compared to the .webm option… and they are 4x bigger

so why are we using .gifs at all? well, Discord accepts NONE OF THESE ALTERNATIVE FILETYPES as options for embeds. so. lame. .gifs are the gold standard in interoperability, so that’s the default

this dilemma spells out one of the key benefits of our “dynamic output” concept; not only are we making emotes contextually reconstructed+resized, we’re also planning on making “full quality originals” in various filetypes available that can be utilized by owners in whatever manner they choose. Discord’s DGAF stance on modern standards shouldn’t limit our users or the countless fun ways they might want to use these emotes

after writing this blog post, i now realize how superficial i am, body shaming gif file size and saying they look like trash… you should join the founder’s mint before i get cancelled

fun bonus fact! whoomp.io uses a .webm/.mp4 switcher wherever possible, letting devices that can view .webm see that version, and defaults to an .mp4 if their browser doesn’t support it. (this .mp4 version does not feature alpha, but sucks to suck, dumb devices!) some whoomp.io assets are still .gifs, because until the whoomp founder’s mint goes live, we don’t have the development resources required to customize some plugins to accept .webm/.mp4 as inputs