Closed Bug 164099 Opened 22 years ago Closed 22 years ago

Unnecessary minimum frame rate delay for GIF anim on Mac

Categories

(Core :: Graphics: ImageLib, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 139677

People

(Reporter: mark, Assigned: jdunn)

References

()

Details

This is a spin off from bug 139677 as suggested by timeless -- I still believe that bug 139677 should be addressed for Mozilla in general, but since Chimera is specifically for OS X only, it makes sense that Chimera might remove the restriction in a more timely manner. I am not sure if I am specifying the proper Chimera component or not. This seems to relate to Performance more than anything else. Anyway, this problem was caused by the "fix" for bug 125137 which implemented a minimum frame rate delay of 100ms for all GIF animations. It is reproducable always. If you look at the animations at http://animecity.nu/Bugzilla/Anim.html or view the image attached to bug 139677 ( http://bugzilla.mozilla.org/attachment.cgi?id=90223&action=view ), you will examples of how Mozilla (and thus Chimera) is now unnecessarily slowing down animations under OS X. From what I can tell, OS X builds of Mozilla were never affected by this particular CPU utilization problem experienced by Windows users. Since the problem was Windows specific, I do not understand why the fix was not also Windows specific. 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 browsers 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. I also oppose the imposed minimum frame rate delay because I think it wrong for According to comments in bug 125137, 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 for Mozilla to second guess the intentions of knowledgeable web developers who are doing the right thing regarding the frame rate. 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 is 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.
Mark, if this is a Mozilla problem, it should be reported on Browser rather than Chimera. Reassigning.
Assignee: bryner → pavlov
Component: Page Layout → Image: GFX
Product: Chimera → Browser
QA Contact: winnie → tpreston
Version: unspecified → other
Whoops, this should just be a dup of your bug 139677. *** This bug has been marked as a duplicate of 139677 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
I see. I read bug 139677 more, and I'll reopen and let the Chimera guys have a look.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Assigning back to Chimera.
Assignee: pavlov → bryner
Component: Image: GFX → Page Layout
Product: Browser → Chimera
QA Contact: tpreston → winnie
Version: other → unspecified
Getting this off the UNCO list.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Seems like this might be a relevant place to look for a start...<br><br> http://lxr.mozilla.org/mozilla/source/lib/liblayer/src/cl_comp.c#1691 <br><br>I might be really confused though too... Not something I feel qualified to be messing with.
There are some tricky issues here with compatibility with animation in other browsers. If we change this, many animations created for Windows IE (like those annoying, frenetic ad banners) may animate too rapidly. In addition, cranking down the threshold may not affect CPU usage with one or two images, but will have significant effects when lots of fast images are present. Marking WONTFIX, sorry.
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WONTFIX
So Mozilla is choosing to be one of the only Mac OS X web browsers that displays these animations WRONG. Nice choice.
"compatibility with animation in other browsers" Translation: Some Windows browsers (not all) display some GIF animations at a slower rate than what is defined within the animation file, therefore the powers that be have decided that Mozilla and all of its descendants will also display the animations incorrectly. BTW, as I have mentioned before, IE for the Mac displays these animations correctly. If Microsoft decides to fix IE for Windows so that it also displays the animations correctly, then will you be willing to have Mozilla fixed so that it displays them correctly again? "In addition, cranking down the threshold may not affect CPU usage with one or two images, but will have significant effects when lots of fast images are present." Do you have definite proof of this or is it theoretical? Before this bogus delay was implemented I tested dozens of web pages and images that were causing CPU usage problems for Windows users; none of them caused any CPU usage problems under Mac OS X. BTW, I do not recall ever seeing any issue with any animations displaying too quickly before this minimum frame rate was imposed, but I certainly have noticed animations displaying too slowly since then. Regardless I do not see that as justification for Mozilla/Chimera to choose to improperly display valid animations with properly configured frame delays. If someone's has improperly set their animation rate too high then that is THEIR problem. The fact that Mozilla can not display many animations properly is Mozilla's problem. Should I start filing bugs for situations where developers sometimes make mistakes that Mozilla could fix for them? For example, if someone creates a web page with black text on a black background, shouldn't Mozilla automatically adjust the text color so that it can be seen?
Ok, reopening, throwing into the Mozilla pool (since this isn't a chimera-specific issue).
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Over to Browser
Assignee: bryner → jdunn
Status: REOPENED → NEW
Component: Page Layout → ImageLib
Product: Chimera → Browser
QA Contact: winnie → tpreston
Summary: Unnecessary minimum frame rate delay for GIF anim → Unnecessary minimum frame rate delay for GIF anim on Mac
Version: unspecified → Trunk
I appreciate this bug being re-openned. However, if it is now redirected back to the general Browser product instead of specifically Chimera, then it is now a dupe of bug 139677. BTW, regarding the issue of the bogus frame rate delay, Apple's newly announced Safari web browser is yet another Mac OS X web browser that displays animations properly rather than following Mozilla's lead in copying the Windows IE flaw of artificially and unnecessarily slowing down web developers animations. *** This bug has been marked as a duplicate of 139677 ***
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.