Shop Mobile More Submit  Join Login
×

Featured in Collections

tl dnr by bipole


More from DeviantArt



Details

Submitted on
March 29, 2007
Link
Thumb

Stats

Views
10,272 (7 today)
Favourites
9 (who?)
Comments
49
×

Frame Delay Times for Animated GIFs

Journal Entry: Thu Mar 29, 2007, 12:00 PM
This journal is a duplication of this news article. It has been provided so that the images needed by the article can be seen.

The Problem

You've had the idea, you've built your emotes, you've put them all together in an animated GIF which you upload for the world to enjoy. The comments start coming in; "Sweet", "Cute", Love it", "Why is it so slow?".  All well and good, apart from that last one.

So you take a closer look and either:
a) you scratch your head and think "it wasn't that slow when I built it"
b) you think it looks fine but other people are still saying it's slow


So what's the problem? The answer is Stupid Browsers.  Simple as that.  Our browsers are just rubbish at rendering fast animated GIFs.

The Theory

An animated GIF file consists of a number of image blocks, each with it's own control block.  The control block includes how long (in 1/100s of a second) the image should be displayed before moving on to the next image.

The GIF Programming Reference[1] has this to say about the frame delay:
Process each graphic in the Data Stream in sequence, without delays other than those specified in the control information.

and
Delay Time - If not 0, this field specifies the number of hundredths (1/100) of a second to wait before continuing with the processing of the Data Stream. The clock starts ticking immediately after the graphic is rendered.

All very simple, the rendering engine should simply wait for the specified delay before moving on to the next image.  No exceptions!  A delay of 0 should be interpreted as instantly displaying the next image and is of no practical use for creating animations. Some programs, JASC Animation Shop for example, will not allow a 0 delay. As each frame in a GIF can have it's own local colour map, some programs have even used the 0 delay to create static GIFs with more that 256 colours[2].

Imagine a series of animated GIFs that all show a progress bar.  These GIFs are identical except for the frame delay.   The first has a delay of 1/100 seconds, the next has 2/100, the next has 3/100, etc. When the first bar has finished the second should be half finished, the next only one third finished, etc.  If you took a screenshot you should see this:

Perfect Browser


The Truth

So that's the theory.  After a number of people had mentioned problems with their animations being slower than they had build them, I decided to investigate and put together a test page containing the GIF progress bars described above.  I then loaded this test page into a number of browser/OS combinations to see what happened.  What I found was a remarkable example of piss poor programming.
  • Mozilla's rendering engine seems to have taken the line that, as screens cannot refresh faster than 90Hz, no one will ever use a delay of 1/100. So a 1/100 delay is changed to 10/100.  Not what you asked for.  Mozilla's answer to the 0 delay is to ignore the specification and use a delay of 10/100.
  • Internet Explorer is even worse.  Any delay less than 6/100 is changed to 10/100.  This is probably based upon the assumption that if 15fps is good enough for cartoons then it's good enough for animated GIFs.
  • Opera is the worst of all.  Every delay below 10/100 is displayed at 10/100.
  • Safari is the best as far as delay cropping is concerned.  It does crop below 3/100, but it crops to 3/100, not back to 10/100.


The figures below show screenshots of the test page displayed by various browsers on different platforms (this test page is available here - you may find this test works best if you download it and run it locally).

Firefox 1.5 on Windows 2000 / XP


Firefox 2.0 on Linux 2.6.5


Firefox 2.0 on Windows XP


Internet Explorer 6 / 7 on Windows 2000 / XP


Mozilla 1.7.6 on Linux 2.6.5


Netscape 8.12 on Windows XP


Opera 9.10 on Windows XP


Safari 1.2 on Mac OS 10.3


Conclusions and Recommendations

If all the browsers followed Safari's example and just stopped making the delays faster then there would not be too much of a problem.  If you ask Safari for a delay of 1/100 seconds and it delivers 3/100 then the animation might not be as fast as you wanted, but it will probably be fast enough.  However, asking Internet Explorer and the Mozilla browsers for 1/100 and getting 10/100 is a significant problem.

So what delays should you use when animating GIFs?  Well never 1/100 or 0; imagine what would happen if one of the popular browsers decided to honour the 0 delay!  As over 2/3 of visitors[3] are using Internet Explorer I'd suggest not dropping below 6/100.  If you really need to go faster than that (and I have seen a few emotes that were stunning at 2/100 in Firefox) then make it clear on your description what browsers it is suitable for. If you're feeling generous then you could always provide an alternative IE version.

Summary

Never, never, never use delays of 0 or 1.
Avoid 2 - 5 if possible.


References

1. GRAPHICS INTERCHANGE FORMAT Version 89a www.w3.org/Graphics/GIF/spec-g…
2. Wikipedia's GIF entry describes True Colour GIFs en.wikipedia.org/wiki/Gif
3. Browser share data provided by leSicilien

  • Mood: Grumpy
Add a Comment:
 
:iconbipole:
bipole Featured By Owner Apr 10, 2013  Hobbyist Digital Artist
IE10 has since improved to 2/100ths, clipping back to 10/100. Safari for Windows and Chrome also match up to Firefox's rendering.
Reply
:iconnoblevalerian:
NobleValerian Featured By Owner Jan 1, 2011  Professional General Artist
useful info!
Reply
:iconivy00:
Ivy00 Featured By Owner Jan 27, 2010
Thanks loads for posting this :)
Reply
:iconlythero:
Lythero Featured By Owner Nov 28, 2007  Hobbyist Filmographer
I already had a decent idea about this problem, but this journal was still very informative about all the specific details. I'll make sure to take these frame rate limits on board. Especially IE's limit. I thought it only started getting crummy below 5/100 8[ stupid browsers.

Well written by the way :nod:
Reply
:iconhumpy77:
humpy77 Featured By Owner Nov 28, 2007
:thumbsup:
Reply
:iconmetaru:
Metaru Featured By Owner Oct 26, 2007
Firefox 2.0.0.3 now supports frame delays up to 2/100
Reply
:iconhumpy77:
humpy77 Featured By Owner Nov 25, 2007
Yup, that's what the tests showed. All the Mozilla based browsers support delays up to 2/100. The problem is that if you specify a delay of 0 or 1/100 they actually use a delay of 10/100.

PS. Sorry for taking to long to reply.
Reply
:iconmetaru:
Metaru Featured By Owner Nov 27, 2007
nevermind. I already knew that, but somehow i got excited that day and wrote that, without noticing that i was already stated in the article. my apologies.
Reply
:iconhumpy77:
humpy77 Featured By Owner Nov 27, 2007
No problem :), I'm just relieved that I don't have to update the journal :D
Reply
:iconbornpessimist:
BornPessimist Featured By Owner Apr 8, 2007  Hobbyist General Artist
Now that's what I call interesting info.
Reply
:iconblackvlindertje:
BlackVlindertje Featured By Owner Apr 1, 2007
Can I ask the most stupid question you'll ever hear now?

I don't get the 1/100 thing. 1/100 of what? *dumb* of a second? I don't get it =p
Reply
:iconhumpy77:
humpy77 Featured By Owner Apr 1, 2007
It's not a stupid question as your animation program might not make it obvious exactly what the delay is. The 1/100 is 1/100 of a second (so you did get it :)).

How you specify the delay will depend on the program you use, but it will be either a fraction, a decimal or a count of hundreths of a second, for example :
  2/100 or 0.02 or 2
  10/100 or 0.1 or 10

Hope this helps :)
Reply
:iconblackvlindertje:
BlackVlindertje Featured By Owner Apr 3, 2007
that's why I never got it. My program just says 0.02 etc.

Thank you for explaining :)
Reply
:iconsethness:
sethness Featured By Owner Apr 1, 2007
5/100 is usually too fast to create a pleasant animation, anyway-- but MAN, I love that you did this research and posted is article. #thunderous applause# Keep it coming!

I didn't know any of that about browsers ignoring our settings in GIF animations-- many thanks for the tutorial.
Reply
:iconcouncilofone:
CouncilOfOne Featured By Owner Mar 30, 2007
Dude, awesome study.

And also explains something I've been wondering for a long time. Cheers, I think I might watch your journals from now on.
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 30, 2007
Thanks :)

You're expecting more like this :o? Arrrrrr, Pressure :fear:!
Reply
:iconcouncilofone:
CouncilOfOne Featured By Owner Mar 30, 2007
Yeah man.

Expectations are the heart of disapointment. I'll be waiting.
Reply
:icondosnerd90:
Dosnerd90 Featured By Owner Mar 30, 2007  Student
Also from what I've heard 24-bit GIFs can't animate, and are quite large.
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 30, 2007
I guess the size problem would be because it would be hard to optimise a tile that was picked just because it have less than 256 colours. At the time it was probably acceptable if you needed a lossless format and couldn't use TIFF.

There no technical reason why a large colour GIF couldn't animate. Probably more a case of the applications that used a 0 delay correctly were not concerned with animation.
Reply
:icondosnerd90:
Dosnerd90 Featured By Owner Mar 30, 2007  Student
"...with more that 265 colours[2]." Shouldn't that be "...with more than 256 colours[2]." That's the kinda mistake I would expect to find in my journals :D.
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 30, 2007
:paranoid: I see no 265! :paranoid: :giggle:

Well spotted! Shame I can't update the news article :(
Reply
:iconkermodog:
Kermodog Featured By Owner Mar 30, 2007
Its a good thing i use safari :)
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 30, 2007
I've now got four browsers installed on the XP machine and two on Linux, but no Safari!
Reply
:iconkermodog:
Kermodog Featured By Owner Mar 30, 2007
thats y u need a mac :|
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 31, 2007
Um, no room on my desk! (besides Old Dogs /= New Tricks :))
Reply
:iconkermodog:
Kermodog Featured By Owner Mar 31, 2007
swap ur pc with a mac :D
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 31, 2007
No! Never! :)
Reply
:iconlinkman428:
linkman428 Featured By Owner Mar 29, 2007
if i ever get into the GIF biz, i'll keep this in mind so that when i get mad over it (its sure to happen) i'll know the reason why! and congrats on the understandibility of this, with me and the others here
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 30, 2007
Glad you get it :). It's a issue that's probably caused an awful lot of head scratching over the years. If this helps some people avoid that then I'm happy :D
Reply
:iconlinkman428:
linkman428 Featured By Owner Mar 30, 2007
you can now die happy!
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 30, 2007
X_X
Reply
:iconlinkman428:
linkman428 Featured By Owner Mar 30, 2007
what perfect timing.
Reply
:iconlivius:
livius Featured By Owner Mar 29, 2007
This is clear, concise, well-written and well-formatted. You are a talented newswriter as well as some kind of gif genius.

How about uploading your pictures to your scraps and using the thumbs in the news article?
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 30, 2007
Thanks liv, I did try the scrappy thumbs route but the images were illegible once they'd been scaled to thumb size.
Reply
:iconlivius:
livius Featured By Owner Mar 30, 2007
Oh, poop. There's gotta be a way...
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 31, 2007
:hmm: I could avoid the scalling by splitting each image into separate tiles and using those thumbs, but the css used on thumbs would then separate and shadow them :(

I did double check with helpdesk about the use of img tags & css in news articles, but it's still not available to us plebeians :)
Reply
:iconshonegold:
ShoneGold Featured By Owner Mar 29, 2007   Digital Artist
Really, really good Steve! :dance:
Reply
:iconpopcorn-pops:
popcorn-pops Featured By Owner Mar 29, 2007  Student Filmographer
Hmm, makes sense...
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 29, 2007
:thumbsup:
Reply
:iconparliamentfunk:
parliamentFunk Featured By Owner Mar 29, 2007
The article has been faved. :D
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 29, 2007
Meep :boogie:
Reply
:iconparliamentfunk:
parliamentFunk Featured By Owner Mar 29, 2007
:dance:
Reply
:icontsemalon:
tsemalon Featured By Owner Mar 29, 2007  Hobbyist General Artist
wow, I can actually understand that!

I dont really get the thing about the example, but really, I get the point =D
*congrats you on getting something like that done by tse*
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 29, 2007
:)

I tried quite a few ways of showing a visual example, nothing was really obvious. But as long as people get the point, I'm happy :)
Thanks :nod:
Reply
:iconlesicilien:
leSicilien Featured By Owner Mar 29, 2007
I am glad that Unisys dropped
the patent - otherwise I
wouldn't bother with gifs at all.

Very good article (must fave).
But anyway -
I think that 10/100, 15/100,
20/100 etc are fine for
emoticon animation purposes.
If one needs something
super-efficient - go for the
.swf plugin (it supports
transparency since version
7 or something). In alternative
PNG + DHTML with some
expertise & it will work the
way one wants to the 1/100th
of second & more.

Glad you found a pretext
to name me also.:)
Reply
:iconhumpy77:
humpy77 Featured By Owner Mar 29, 2007
Thanks. I've never done anything with swf but it does seem to be more resistant to performance problems.

:D
Reply
:iconlesicilien:
leSicilien Featured By Owner Mar 29, 2007
Swf, as plug-in, is totally
independent from the
browser & quite separated
from the platform as well
[somewhat it is java applets' heir].
So it will respect it own internal
scripting instructions. A bit heavy
RAM-wise but one won't notice
on modern machines. Since
there is thetransparency - it is
quite able to replace some gifs.:)
Thx again for the mention.:):)
Reply
Add a Comment: