Closed Bug 232769 Opened 21 years ago Closed 21 years ago

Animated GIF file animates too quickly

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: ali, Assigned: jdunn)

References

(
URL
)

Details

Attachments

(3 files)

Animated GIF that plays too quickly
59.67 KB, image/gif
Details
The same GIF with 50ms delay
59.68 KB, image/gif
Details
The same GIF with 100ms delay
59.68 KB, image/gif
Details 
User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040131 Firebird/0.8.0+

This particular GIF file animates itself far too quickly. In IE, the rendering
speed is normal, and in 2004-01-16 builds of Mozilla, the speed is also normal.
So the regression window is somewhere between then and now.

URI for image:
http://home.bellsouth.net/coDataImages/p/Groups/180/180458/folders/125916/877895vanessa-ploid.gif

Reproducible: Always
Steps to Reproduce:
1. Go to URI in comment 0
2.
3.

Actual Results:  
GIF animates itself too quickly

Expected Results:  
GIF should animate at a normal speed
This is a copy of the GIF from comment 0.
Caused by bz's checkin for bug 207059.
bz's checkin for bug 207059 was on 2004-01-06, but the 2004-01-16 build displays
the above GIF at a normal speed. Therefore shouldn't the regression have occured
after this date?
Keywords: regression
As per this MZ thread, it's possible that the new behaviour is actually correct
(but I'm not sure about this). I'm including the link so that people more
familiar with the code can check it out and decide for themselves:

http://forums.mozillazine.org/viewtopic.php?t=48944
Are you testing a mozilla.org trunk build or a contributed binary, branch,
or other product (ie, firebird)?
Keywords: regression
My bugreport is based on testing on both the Seamonkey trunk (official builds)
and Firebird trunk (official buids). In this case, Firebird and Seamonkey
2004-01-16 trunk both display the GIF slowly, and Firebird and Seamonkey trunk
2004-01-31 both display it quickly.
The mentioned GIF has a frame rate delay of 20ms, which leads to a loop time of
1s for its 50 frames, so IMO Firebird aebrahims build animates it correctly.
Here's the same GIF with a 50ms delay:
Another version to compare.
Frankly, I think we simply do not care.  See the data in
http://bugzilla.mozilla.org/show_bug.cgi?id=139677#c11

It seems that the limit in IE has already slipped from 100ms to 50ms between
IE5.5 and IE6.  It's going to keep slipping further (since there's no reason not
to), and I see no reason to keep revisiting this issue every time IE changes its
behavior.  We should just do what Opera does (and what we do now), imo.

Not marking this wontfix, since this is not my module...
Also, I see identical behavior in 2004-01-06, 2004-01-16, and current SeaMonkey
trunk builds on Linux, and different behavior in 2004-01-05 builds (as
expected).  So I have no idea what's up in comment 3.
RE comment 10, after testing this again I think I've been doing something wrong,
because I'm now also seeing the same behaviour in all these builds after
2004-01-06. I'm not going to mark INVALID because comment 9 raises the issue of
what we want to do (if anything) about the disparity in speeds, so the module
owner can do the needful.
tor, your call.
What we do now seems reasonable - if anything I'd drop our threshold
even lower.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
I would vote for dropping the threshold lower.

Mozilla should display GIF animations at the rate specified in the GIF.  If the creator of the GIF, 
unintentionally sets a frame rate that is too high for his animation, then that is his error.  If the 
creator of a GIF intentionally sets a very high frame rate and Mozilla slows it down, then that is 
Mozilla's error.  Mozilla should follow the specs instead of trying to make assumptions about how 
the GIF creator might have accidently set the wrong delay.
Mark, where is the threshold now?
(In reply to comment #15)
> Mark, where is the threshold now?

As per the patch attached to bug 207059, when Mozilla encounters a GIF animation with a delay 
set to 10ms or less, Mozilla changes the delay to 100ms.

I have been working on non-Mozilla related projects lately and thus have not pulled down the 
source to verify that that is still the prevalent code, but unless you checked in a modified version of 
the patch or someone else checked in a patch that I am not aware of, 11ms is the minimum delay 
that Mozilla supports.

IMO, there should be no forced minimum.  If the GIF specifies a 1ms delay then Mozilla should 
display it with a 1ms delay.  If the GIF specifies 0 then Mozilla should display the GIF without any 
artificial delay.  That is the proper behavior according to the GIF specs.

If Mozilla wants to have some default minimum frame rate delay, then it should be done via a patch 
for Bug 71829 whereby the Mozilla user can choose the minimum frame delay. 
*** Bug 232822 has been marked as a duplicate of this bug. ***
*** Bug 242258 has been marked as a duplicate of this bug. ***
*** Bug 241538 has been marked as a duplicate of this bug. ***
*** Bug 239842 has been marked as a duplicate of this bug. ***
*** Bug 246602 has been marked as a duplicate of this bug. ***
(In reply to comment #16)
> IMO, there should be no forced minimum.  If the GIF specifies a 1ms delay then
Mozilla should 
> display it with a 1ms delay.  If the GIF specifies 0 then Mozilla should
display the GIF without any 
> artificial delay.  That is the proper behavior according to the GIF specs.
I agree
*** Bug 246970 has been marked as a duplicate of this bug. ***
*** Bug 248774 has been marked as a duplicate of this bug. ***
*** Bug 249927 has been marked as a duplicate of this bug. ***
*** Bug 243892 has been marked as a duplicate of this bug. ***
preference bug filed: bug 252244
*** Bug 239351 has been marked as a duplicate of this bug. ***
*** Bug 261827 has been marked as a duplicate of this bug. ***
*** Bug 262407 has been marked as a duplicate of this bug. ***
*** Bug 283126 has been marked as a duplicate of this bug. ***
How do you fix this problem?
You email Microsoft and ask them to fix the code in IE that ignores the
animation settings in GIFs and imposes a maximum frame rate.
Why is this resolved as wontfix?  I'm using Firefox 1.0 (current as downloaded
from the homepage) and I still see this problem all over.  GIFs play the same
speed in Internet Explorer (6.0), Opera (7.54), and Windows Picture Viewer.

However, they play at Mozilla speed in Quicktime or MPlayer Classic.  This is
more than twice as fast, and seemingly quite a bit faster than the author intended.

I've never seen another browser that plays gifs at your speed.  Are you saying
everyone else has got it wrong?

For a lot of gifs to compare this, try Shorky's Animated Gif Theatre
http://shmorky.com/d/20040312.html

P.S.  If this really is an improvement on standards, it does help dynamic
webpages.  If only Firefox would handle the javascript setTimout() function as
smoothly as IE does, so I could create better dynamic content for it.  IE runs
this thing I made much faster: http://nick-zap.home.comcast.net/linkcontrol.htm
(do not judge by what seems the intended speed, it's just an experiment.  IE
runs it better).
(In reply to comment #34)
> I've never seen another browser that plays gifs at your speed.  Are you saying
> everyone else has got it wrong?

Yes, that's exactly what we are saying.  The GIFs have been created in programs
that assumed "< 50ms delay == 100ms delay" or on even some older versions "<
100ms == 100ms delay".  They assumed this because that's what IE and Netscape
did, instead of following the spec.  There's various reasons for not following
the spec, ranging from not enough CPU power to animate that fast, to developers
deciding it was more important that their GIF module followed what "the popular
browsers" did.

Well you may be right, but having a unique interpretation of web pages is
generally not a good thing.  I think there should be a setting (under
Advanced->Browsing, next to Image Resizing, perhaps) that makes it "Play GIFs at
real speed" or not, so that someone can uncheck this if they want the same
behavior as in other browsers when handling gifs.  Perhaps even a DOM entry, for
the sake of control freaks.
There is bug 71829 for specifying the delay for GIF frames with no delay. But
the decision has been made to honor all delays of 20 ms or more, so you're going
to have to live with it.
In addition to Bug 71829 , you may also want to look at Bug 252244 regarding the request for 
minimum delay rate preference settings for animated GIFs.  

As for the issue of having a unique interpretation of web pages, AFAIK, it is primarily Windows based 
web browsers that are imposing a 100ms minimum delay.  I have half a dozen different web browsers 
on my PowerBook (including MS Internet Explorer) and none of them force a 100ms delay.  

Rather than try to convince Mozilla and all other browsers to interpret the GIF spec wrongly, you should 
try to convince the Windows web browsers to do it right. Or else encourage web developers to specify 
the frame delay that they actually want to use.
> Well you may be right, but having a unique interpretation of web pages is
> generally not a good thing. 

Unique?  IE5 and IE6 on Windows behave differently with regard to GIF animation.
  IE5/Mac behaves like Mozilla.  Opera behaves differently from IE5/6 and
differently from Mozilla.  Safari behaves like Mozilla, last I checked.

So it's not as if all browsers are doing one thing and Mozilla is doing
something else.  Given the further fact that IE/Windows (which is furthest from
following the GIF standard here) is slowly drifting closer to it (the threshold
below which the timeout is ignored is lower in IE6/Win than in IE5/Win), there
is really no reason we should be doing anything but folowing the standard and
waiting the release or two it'll take IE/Win to get there.
I think that it is necessary to change status REOPEN.

Frame rate is normal:
IE8
Google Chrome 4.0.294.0
Safari4.0.4(531.21.10)

Frame rate is  very fast:
Opera 10.10
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2pre) Gecko/20100113 Namoroka/3.6pre ID:20100113045128
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100114 Minefield/3.7a1pre ID:20100114042800
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: