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.