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)
Core
Graphics: ImageLib
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.
Comment 1•21 years ago
|
||
Please post references to the earlier bugs on this topic, which have the rather
extensive discussion and data that led to the current behavior!
Reporter | ||
Comment 2•21 years ago
|
||
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.
Comment 3•21 years ago
|
||
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.
Reporter | ||
Comment 4•21 years ago
|
||
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
Reporter | ||
Comment 6•21 years ago
|
||
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.
Reporter | ||
Comment 8•21 years ago
|
||
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.
Description
•