you are viewing a single comment's thread.

view the rest of the comments →

[–]alofons 0 points1 point ago


That's interesting. I was talking from experience and intuition, since many GIFs have a huge size, and when I'm looking at a GIF loading, each frame seems to take roughly the same time.

I have done a simple test, using Imagemagick's "convert" to make a GIF consisting on some equal frames. The result is completely linear.

10 equal frames: 23551 bytes
20 equal frames: 46301 bytes
30 equal frames: 69051 bytes
40 equal frames: 91801 bytes
50 equal frames: 114551 bytes

(For reference, the original image is 64x64=4096 bytes when palettized to 256 colors, and the GIF size increases 2275 bytes per frame including LZW compression, so it looks like the entire image is being encoded).

If a popular program such as ImageMagick does that, I imagine that there may be many more programs that also do it. Maybe there's some limitation on this approach, or maybe no one has bothered to implement it (like true color GIFs).

A wild guess: Each GIF image/frame can only have one image descriptor. One can use it to specify the rectangle to be updated. Wouldn't this mean that if a pixel changed near the top-left corner, and another near the bottom-right corner, the whole frame would need to be retransmitted?

[–]riplin 0 points1 point ago*


I think you can get creative with the frame time though. But this is pure speculation. If you create 2 frames and set the delay to 0ms, it could update in the same 'frame'. But again, that's pure speculation.

Oh! There's also transparency, so that probably helps trim it down for parts of the screen that didn't change.