Animated gifs animate faster if you move the mouse pointer around.




19 years ago
5 years ago


(Reporter: a-huntwork, Assigned: pavlov)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [imglib], URL)



19 years ago
Many nightly builds up to 4-6 and probably past.

Open the URL in mozilla.  Move the mouse pointer around rapidly inside the
window in which the gif appears.  Notice that the speed is faster while you're
doing this than when you're not moving the pointer.  This is a general problem
with animated gifs in mozilla.  The throbber will exhibit this behavior also if
you can manage to get it to spin for long enough to test (and spinning a lot is
not something mozilla really has a problem with).
can you please download a m16 nightly and check, as I cannot see this.

Comment 2

19 years ago
I can reproduce this on the 4.24.00 AM Netscape Commercial Linux build. 
Confirming. Good catch!
Ever confirmed: true

Comment 3

19 years ago
just a comment: The general problem with animated gif's in moz (linux) seems to
be that they initially animate to *slow*! To see this how this works: just open
bonsai page while the flame-gif's are animating. Load the same page in NC4.7.
They "burn" 4 times faster or more in NC.

Comment 4

19 years ago
>>The general problem with animated gif's in moz (linux) seems to
>>be that they initially animate to *slow*!

More of a symptom than the problem. The problem is the X front end
rendering code needs work. Animations suck up cpu on X like you
wouldn't believe. There may be some odd dynamics with animations in
tables also. Tinderbox is a prime example.

Target Milestone: --- → M18

Comment 5

19 years ago
*** Bug 36370 has been marked as a duplicate of this bug. ***

Comment 6

19 years ago
you're right..also about strange dynamics regarding aminated gifs and
See now on tinderbox where speedracer have 5 gifs and is the only cell with it.
It's slightly slower than on NC4.7 but way faster than if 5 of same gif are in 5
different cells.


19 years ago
Target Milestone: M18 → Future

Comment 7

19 years ago
this work on a winNT platform but it hasn't tested it on the linux platform.


19 years ago
Blocks: 61527


19 years ago
QA Contact: elig → tpreston


18 years ago
Blocks: 66964


18 years ago
Blocks: 66966

Comment 8

18 years ago
The URL given is unavailable (sometimes?), try:
instead.  This bug doesn't just apply to animated images, it also has an effect on:

It seems that the mousing has to be done over the page itself, try resizing the
window and mousing over the desktop: no effect.

Normally the expando demo uses ~12% CPU, waving the mouse about raises this to
~40%.  For the hauppage page the figures are about 8% and 20%.  Moving the mouse
elsewhere uses no measurable CPU.

Don't know what all this means ;)

Comment 9

18 years ago
This one isn't just Linux, i also get it on Windows Me.
It affects the progress indicator bar at the bottom too.

Comment 10

18 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov

Comment 11

18 years ago
Actually if you move the mouse, the animation will hiccup for a second, 
specifically if you mouse over xul or chrome  (Kevin, peterl wanted you added to 
this list)
Whiteboard: [imglib]
You can really see this bug well on both Windows and Linux at this URL:

The gif also pauses when you open new windows.

Comment 13

18 years ago
I don't think that this bug is related to imglib. I've seen this bug with all
animations whether DHTML, or Gifs. This makes me think its some sort of
rendering bug. Maybe someone should bump this over to "compositor" to see what
they have to say.

Comment 14

18 years ago
could this be related to some event system in the chrome? Like detecting "mouse
over", "mouse move"?  Or related to some javascript in the chrome?

Comment 15

18 years ago
I found and example of this happening in Javascript animation. Actually its been
under our "Debug" Menu the entire time. resource:///res/samples/test13.html

its Debug | Verification | transparency.

I guess its to check the transparency of the divs, but since they are animated
it also demonstrates this problem.

whether this is related I don't know, but it seems too coincindental. 

Comment 16

18 years ago
FYI, that "phenomenon" is reported in bug 69803.

Comment 17

18 years ago
Another testcase: attachment 41480 [details]


17 years ago
Blocks: 119597

Comment 18

17 years ago
I don't see any problems on testcases of comments #12 and #17 with Linux
2002012808. The animation doesn't change when I move or not move the mouse. It
animates on constant speed.
Marking WFM.
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 19

17 years ago
Verified WFM linux build 2002012808
You need to log in before you can comment on or make changes to this bug.