3 ms·

This would probably cause regressions with other GIFs that neglect to specify a delay but are supposed to have one. It's hard to imagine this universal behavior

by chc 12y ago

This would probably cause regressions with other GIFs that neglect to specify a delay but are supposed to have one. It's hard to imagine this universal behavior is accidental. It's probably like everything else on the Web — a hack to keep things that shouldn't work from actually not working.

wzdd 12y ago
I'm fairly sure that the reason for this universal behaviour is that there are plenty of broken, looping gifs out there with inter-frame delays of 0. I used a version of Konqueror which would spin at 100% of a core when it encountered one of these. A better hack (but it's still a hack) might be to wait one frame (or longer) before returning to the beginning of a looping gif. Given that this would be significantly harder than the current approach (which is apparently either delay = max(delay, 16ms) or if(delay < 16) delay = 100) and the only reason for it would be to support this pretty-niche multi-palette composited-frame thing, it seems like it would be hard to argue for.
eridius 12y ago
Are there GIFs that specify a delay on some frames but not others, and expect all frames to have a delay? Because it should be easy to detect animated GIFs that specify no delay for any frame, and treat them all as having a delay.
- chc 12y ago
  As I understand it, that would still block this "large-palette GIF" trick, because those would also consist entirely of frames with no delay.
  - eridius 12y ago
    I assumed that the "large-palette GIF" would have animation. Otherwise, why are you bothering with tricky GIFs at all, why not just use a PNG (or JPEG, depending on the image type)?
- neolefty 12y ago
  A workaround for the workaround: for a high-color gif, add a blank "animation" frame at the end that has a delay, after all the no-delay buildup elements. However, that's unlikely to be necessary because if you are just doing a high-color image with no animation, you may as well use JPEG or PNG.

by chc 12y ago

wzdd 12y ago

I'm fairly sure that the reason for this universal behaviour is that there are plenty of broken, looping gifs out there with inter-frame delays of 0. I used a version of Konqueror which would spin at 100% of a core when it encountered one of these. A better hack (but it's still a hack) might be to wait one frame (or longer) before returning to the beginning of a looping gif. Given that this would be significantly harder than the current approach (which is apparently either delay = max(delay, 16ms) or if(delay < 16) delay = 100) and the only reason for it would be to support this pretty-niche multi-palette composited-frame thing, it seems like it would be hard to argue for.

eridius 12y ago

Are there GIFs that specify a delay on some frames but not others, and expect all frames to have a delay? Because it should be easy to detect animated GIFs that specify no delay for any frame, and treat them all as having a delay.

chc 12y ago
As I understand it, that would still block this "large-palette GIF" trick, because those would also consist entirely of frames with no delay.
- eridius 12y ago
  I assumed that the "large-palette GIF" would have animation. Otherwise, why are you bothering with tricky GIFs at all, why not just use a PNG (or JPEG, depending on the image type)?
neolefty 12y ago
A workaround for the workaround: for a high-color gif, add a blank "animation" frame at the end that has a delay, after all the no-delay buildup elements. However, that's unlikely to be necessary because if you are just doing a high-color image with no animation, you may as well use JPEG or PNG.