Closed Bug 232822 Opened 21 years ago Closed 21 years ago

Animated GIF frame delays of 10 ms are slowed to 100 ms

Categories

(Core :: Graphics: ImageLib, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 232769

People

(Reporter: schapel, Assigned: jdunn)

Details

(Whiteboard: parity-ie/mac)

Currently, Mozilla shows most animated GIF frames for the delay time specified in the GIF. The exceptions are the delays of 0 ms and 10 ms. Mozilla changes both of these delays to 100 ms to match most other browsers, most notably IE/Win 6 and Opera 7. The case of 0 ms is handled by bug 71829, which requests a user settable delay to replace the 0 ms delay. This bug requests that GIF animation frame delays of 10 ms be honored on all platforms. This will allow Mozilla to have better standards compliance and display higher quality animations.
Please post references to the earlier bugs on this topic, which have the rather extensive discussion and data that led to the current behavior!
Originally, Mozilla honored all animated GIF delays. However, small frame delays caused problems and bug 125137 was created. The fix for that bug was to follow IE's de facto standard of a 100 ms minimum frame rate delay. That fix caused GIFs to be animated too slowly (especially after IE's de facto "standard" changed and Opera made their own de facto "standard") and as a result bug 139677 and bug 207059 (and others) were created in an attempt to allow Mozilla to show fast GIFs at the correct rate. The fix for bug 207059 caused Mozilla to honor delays of 20-90 ms, but to still slow 0 ms and 10 ms delays to 100 ms. This slowing of 0 and 10 ms delays matches nearly all other browsers and many graphics tools. However, this slowing is still technically a standards violation that this bug requests be removed from Mozilla. Perhaps fixing this bug now would result in an overall worse user experience due to many GIFs being displayed ten times more quickly than in other browsers. But maybe someday all browsers, including Mozilla, will display GIFs at the correct speed.
Just a nit, but actually Mozilla changes slows down delays of 1ms - 9ms as well as 0 and 10ms. To make my post more worthwhile, I will include what the most current versions of some other browsers are doing : Mac IE 5.2.3 changes a 0 delay to a 50ms delay. No change for 10ms delay. Mac Opera 6.03 changes a 0 delay to a 100ms delay. No change for 10ms delays. I am not sure what Safari is doing, but it appears to change anything with a 0 - 40ms delay to a 40ms delay. That may not be exactly what is going on, but that is what it looks like from brief observation.
According to the GIF89A specification at http://www.w3.org/Graphics/GIF/spec-gif89a.txt the Delay Time field is a 16-bit unsigned integer that specifies the delay in hundredths (1/100) of a second. The only allowable delays therefore are 0 ms, 10 ms, 20 ms, etc. Mozilla correctly supports all delays of 20 ms and over. The only two delays left are 0 ms and 10 ms. BTW, if someone give us the URL of a GIF on the Internet that deliberately uses 10 ms frame delays, that would help convince others that this bug should be fixed and would also help test the patch.
Whiteboard: parity-ie/mac
*** This bug has been marked as a duplicate of 232769 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
I don't see how this bug is a duplicate of bug 232769. That bug says that Mozilla runs GIFs too quickly. This bug says that Mozilla runs GIFs too slowly. Mozilla in fact does run fast GIFs more slowly than the GIF89a specification states.
It's a dup because both bugs are discussing the same four lines of code that determine how the GIF delay times are mapped.
Okay. But then isn't bug 71829 also a dupe of bug 232769 since fixing that bug would alter the mapping, too?
You need to log in before you can comment on or make changes to this bug.