The fix for bug 125137 implemented a minimum frame rate delay of 100ms for all GIF animations. The motivation to implement a 100ms minimum frame rate delay seemed to be : 1) Because high frame rate animations were sometimes causing excessive CPU utilization on Windows; by reducing the frame rate, CPU utilization was reduced. 2) The presumption was that developers who created animated GIFs with higher frame rates were doing so out of ignorance because they were previewing their animations in IE for Windows which automatically slowed animations down to a minimum of 100ms. My reasons for openning this bug : 1) From what I can tell, OS X builds of Mozilla were not affected by the CPU utilization problem experienced by Windows users. Since this aspect of the problem was Windows specific, I do not understand why the fix was not also Windows specific. 2) The 100ms minium delay was declared a defacto standard because IE and some other browsers for Windows used it. However, IE 5.1 and other OS X browser do not impose this 100ms limitation. If this is a defacto standard then it is a defacto standard for the Windows platform; it is not a defacto standard for OS X. So again I question why this Microsoft Windows IE implemented limitation has been imposed upon OS X Mozilla users. 3) Regardless I think it wrong for Mozilla to second guess the web developer's intentions regarding the frame rate. I understand that some ignorant web developers are accidently specifying higher frame rates than what they really want, but that is THEIR error; it is not a reason to prevent knowledgeable web developers from having their animations displayed at the rate that they specify. If a web developer wants to put a 30fps GIF animation on his website, this minimum delay will prevent Mozilla from displaying the animation at the intended frame rate -- and that would be MOZILLA's error. Since OS X builds of Mozilla do not seem to have any problem displaying high frame rate animated GIFs and since the 100ms minimum delay is not used by IE 5.1 for OS X or iCab for OS X, I am suggesting that this minimum frame delay be disabled for OS X builds of Mozilla. Otherwise it will look like the OS X Mozilla can not display animations as quickly as other OS X browsers. The url cited above ( http://animecity.nu/Bugzilla/Anim.html ) is the example used in bug 125137 and it shows 4 animated gifs set to 10ms, 50ms, 100ms, and 200ms delays. All current builds of Mozilla show the first 3 at the same 100ms speed, but if you go back to OS X builds prior to 4-8-2002, Mozilla will display the GIFs at approxiamately the speed specified. If you check this URL with IE 5.1 for OS X or iCab 2.7 for OS X, you will see that they display the GIFs at the correct speed the same as the older Mozilla builds did. Note : I have not tested any MacOS Classic builds. Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020422

*** Bug 142398 has been marked as a duplicate of this bug. ***

I think the best idea is to have a pref (UI-settable probably not needed) for it, and default it to 100ms for PC (as it is now) and probably 10ms for MAC. Then, as time goes by and CPUs get faster, we can adjust the default for PC to something closer to 10ms. If we chose to do it this way, then this bug is very much related to Bug 71829.

we have enough prefs in the app and i'm not going to add any more from imagelib. While I understand what you are saying, I think we should leave it how it is. We don't want even more differences for web developers to have to deal with imho.

Web developers who use Macs are currently having to deal with the fact that Mozilla for OS X (and soon Netscape 7 for OS X) can not display GIF animations with anything less than a 100ms delay -- meanwhile IE 5.1 on OS X and iCab on OS X can display animations at their designated speed. Thus this bug is creating a difference in how GIF animations are displayed for Mac web developers. And out of the three Mac web browsers mentioned, the only one that is displaying the animations WRONG is Mozilla. If you need to future it then I can accept that, but you are not doing web developers any favor by doing so.

This cool little animated GIF of a dancing penguin can be found running wild throughout the Internet. I have seen him many times in the past and Mozilla had always displayed him properly, but until today, I had not seen him since the "fix" for bug 125137 was implemented; now I have to switch to IE or iCab in order to see the animation displayed correctly.

yep the penguin looks cool on w2k in n4, and looks awful on w2k in ie5.5

I just now downloaded Chimera 0.4 and unfortunately it also has this counterproductive frame rate delay. What is proper means of getting this on the Chimera group's radar? Should I file another bug specifically addressed to the Chimera product or just drop an email to point out the bug to someone? Whether or not the Mac versions of Mozilla and Netscape adhere to the alledged Windows de facto standard of slowing down web designer's animations, Chimera, being specifically developed for OS X, should follow the Mac de facto standard of properly displaying animations at their designated speed.

File a bug on the Chimera product. Reference this bug in its description.

*** Bug 164099 has been marked as a duplicate of this bug. ***

*** Bug 164099 has been marked as a duplicate of this bug. ***

Changing URL. Added an additional tests for 20ms, 30ms, 40ms, and 50ms. Mozilla 2003010205: All go the same speed except 200ms. IE 6/Win: 10 - 50ms go 100ms >50ms go correct speed Opera 7b2/Win: All go correct speed Opera 6/Win: All go the same speed except 200ms. I'd like to see results for IE Mac, and even Safire if anyone wants. It's interesting that Opera 7 has removed the limit. Maybe they think computers are fast enough these days?

err.. Safire == Safari

Opera 7 final/Win: 10ms goes 100ms Rest go correct speed I wouldn't mind doing what Opera 7final is doing. The biggest reason we have a minumum delay is because people incorrectly set their GIF frame delays to 0 or 10ms when they really want 100. Forcing <= 10ms to 100 and leaving the rest at the correct speed would be optimal. Still waiting for a Mac person to post their results (as per Comment #11)

On my 800Mhz Powerbook G4, IE and Safari both display the 20ms-200ms animations on the test URL correctly. The 10ms animation seems to be displayed at approxiamately the same rate as the 20ms animation. However I am not sure if that is due to a limitation of the browser software or if it is a frame rate limitation of my hardware. As I have pointed out before, Macs running OS X were never subject to the CPU utilization problems that were being addressed in bug 125137.

With the latest imglib patches, the minimum frame rate may not be a problem on Windows either...

Note bug 71829

Bug 71829 is about animated GIFs which do not specify a delay. This bug is about the fact that Mozilla is OVERRIDING specified delays that have been properly defined in high speed animated GIFs. If Mozilla would only impose this minimum frame rate delay when the GIFs do not specify a delay then I would be much happier.

I just confirmed bug 207059, which is for supporting faster animated GIFs on all platforms. If you want faster GIFs on platforms other than Mac OS X, I suppose you're really interested in that bug, instead.

The unnecessary minimum frame rate delay has now been fixed by bug 207059 on all platforms. *** This bug has been marked as a duplicate of 207059 ***

I have been tempted to reopen this bug ever since it was closed, but I will continue to refrain for now and just leave this comment. Although the fix for bug 207059 does definitely improve things, there is still an unnecessary minimum frame rate delay being imposed by Mozilla. Mozilla should not override the animation settings specified in an animated GIF. Mozilla has absolutely no way of knowing whether the frame delay was set intentionally or out of ignorance. It is wrong for Mozilla to assume that it was set out of ignorance. Mozilla should follow the GIF spec and leave it up to the ignorant GIF creators to fix their own problems. When an ignorant web developer accidently sets his background to the same color as his text, does Mozilla presume to adjust the color so that the text can be seen? No, because there are legitimate reasons for setting the colors to match. Likewise there are legitimate reasons to have a GIF animations with a 10ms delay and Mozilla should not presume to force it to slow to 100ms.

Mark, the problem is that there are GIF authoring _tools_ out there, apparently, that will set incorrect frame rate delays (0ms and 10ms, to be exact). So it's not a matter of ignorance, but of malice.

(In reply to comment #21) > Mark, the problem is that there are GIF authoring _tools_ out there, apparently, > that will set incorrect frame rate delays (0ms and 10ms, to be exact). So it's > not a matter of ignorance, but of malice. Malice?? There is nothing malicious about it. There is nothing inherently wrong with a high speed GIF. A 10ms frame rate delay is only "incorrect" if the person creating the GIF did not want to have a 10ms delay. Every GIF authoring tool that I have ever seen will allow the person to set the delay. If the person creates a GIF with a 10ms delay when they really wanted a 100ms delay, then it is the result of ignorance, not malice. The error belongs to the author of the GIF. If there is a GIF authoring tool that sets the delay to 10ms when the person specifies a different delay then that would be a bug in that program, but it would be ignorant for the person to continue to use that program to create GIFs. The error still belongs to the author of the GIF. If someone intentionally creates a GIF animation with a 10ms delay, Mozilla will display it incorrectly. In this case, the author of the GIF has done nothing wrong. The error belongs to Mozilla.

> Malice?? There is nothing malicious about it. There is nothing inherently > wrong with a high speed GIF. The malice is that said tools give the author the impression that the gif will run at a much lower speed. Quite frankly, there are very few monitors out there capable of showing anything at a refresh rate of over 100Hz (which is what you need for sub-10ms speed). And at the moment, this particular neck of the "standards" woods is so poorly implemented in browsers and so commonly abused that having this intentional quirk in our rendering is justified.

(In reply to comment #23) > > The malice is that said tools give the author the impression that the gif will > run at a much lower speed. The authoring tools are flawed and the user of those tools is ignorant. I still do not see the malice in it. I see more malice in the fact that Mozilla currently will arbitrarily change a 10ms delay into a 100ms delay. How are GIF animators supposed to know that Mozilla will honor an 11ms delay, but not a 10ms delay? Are GIF animators supposed to understand why Mozilla displays a GIF with a 10ms delay approximately ten times slower than a GIF with an 11ms delay? > Quite frankly, there are very few monitors out there capable of showing anything > at a refresh rate of over 100Hz (which is what you need for sub-10ms speed). However, there are monitors which are indeed capable of properly displaying a GIF animations with a 10ms delay. Regardless, how does the that justify changing a 10ms delay into a 100ms delay? If the issue is simply that monitors can not display the animation that fast then why not make sub-10ms delays become 10ms delays or 20ms delays? Why 100ms? The intended purpose of a 0 delay is to display the animation as fast as the hardware can handle; instead Mozilla slows those GIFs down to one frame per second. > And at the moment, this particular neck of the "standards" woods is so poorly > implemented in browsers and so commonly abused that having this intentional > quirk in our rendering is justified. I did not reopen the bug. As I stated before, I was simply posting my comments to note my position against its closure. I still believe that the current behavior is wrong, but we are better off than we were and I have no intention of pressing the issue at this time. I will say though that rather than having this limitation hard coded into the source, I would prefer to see the minimum frame rate delay implemented as the default setting in a patch for bug 71829.

> The authoring tools are flawed and the user of those tools is ignorant. I > still do not see the malice in it. The malice is in the tool itself... > will arbitrarily change a 10ms delay into a 100ms delay. It's not completely arbitrary. It's more of a de-facto standard for web browsers than anything else. See comment 11 and comment 13. > Regardless, how does the that justify changing a 10ms delay into a 100ms > delay? That's what every single other commonly used browser (except perhaps Safari) does. > The intended purpose of a 0 delay is to display the animation as fast as the > hardware can handle In theory, yes. In practice, the number of gifs with a 0 delay that are meant to display with a 100ms delay completely swamps the number of gifs with a 0 delay that are meant to display as fast as possible. This is a tradeoff that comes up a lot with web technologies -- making a choice between complete support for a standard that no one else supports or making some concessions to de-facto practices. In this case, the module owner (not me, btw) has made that choice. > instead Mozilla slows those GIFs down to one frame per second. "ten". ;) People are free to make this a pref (and have it default to whatever they want to), of course. I doubt anyone would really mind that.

The complaint about 10 ms delays is a valid one, and I've created bug 232822 to cover the slowing of 10 ms frame delays on all platforms. Bug 71829 covers the 0 ms case, so that should cover all the cases in which Mozilla breaks the GIF89a spec in relation to animation delays.

(In reply to comment #25) > > will arbitrarily change a 10ms delay into a 100ms delay. > > It's not completely arbitrary. It's more of a de-facto standard for web > browsers than anything else. See comment 11 and comment 13. > > > Regardless, how does the that justify changing a 10ms delay into a 100ms > > delay? > > That's what every single other commonly used browser (except perhaps Safari) does. It may be some kind of de-facto standard for Windows browsers, but AFAIK, Mozilla is the ONLY browser on the Mac platform that changes a 10ms delay to 100ms. Mac IE changes a 0 delay to a 50ms delay. No change for 10ms delay. Mac Opera changes a 0 delay to a 100ms delay. No change for 10ms delay. I am not sure what Safari is doing, but it appears to change anything with a 40ms delay or less to a 40ms delay. > In practice, the number of gifs with a 0 delay that are meant to display > with a 100ms delay completely swamps the number of gifs with a 0 > delay that are meant to display as fast as possible. I am not sure what kind of study was done to determine that statistic, but it is hardly surprising that the number of ignorant people outnumber the informed ones. Regardles it does not seem like sufficient justification for Mozilla to do the wrong thing. When someone creates an animated GIF with Adobe ImageReady or GIMP and they intentionally specify a 10ms delay, Mozilla should not override that setting just because some other people use inferior GIF authoring tools. (I encountered a mid-air collision with Comment 26. Posting this comment here to counter the Comment 25 statement about what other browsers are doing, but any further discussion should probably go to Bug 232822 or more possibly to email.)