Hacker News new | past | comments | ask | show | jobs | submit login

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.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact