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

Status: VERIFIED WORKSFORME

(Core :: Graphics: ImageLib, defect, P3)

Description

[a-huntwork]

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).

Comment 1

[Doron Rosenberg (IBM)]

can you please download a m16 nightly and check, as I cannot see this.

Comment 2

[Eli Goldberg]

I can reproduce this on the 4.24.00 AM Netscape Commercial Linux build. 
Confirming. Good catch!

Comment 3

[R.K.Aa.]

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

[pnunn]

>>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.
-P

Comment 5

[Eli Goldberg]

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

Comment 6

[R.K.Aa.]

you're right..also about strange dynamics regarding aminated gifs and
cells/tables:
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.

Comment 7

[kenneth buttler]

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

Comment 8

[Alistair Vining]

The URL given is unavailable (sometimes?), try:
http://www.hauppauge.co.uk/html/new.html
instead.  This bug doesn't just apply to animated images, it also has an effect on:
http://www.mozilla.org/newlayout/demo/expando.html

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

[Ferdinand]

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

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 11

[Terri Preston]

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)

Comment 12

[Stephen Ostermiller]

You can really see this bug well on both Windows and Linux at this URL:
http://www.rpfuller.com/ugh.gif

The gif also pauses when you open new windows.

Comment 13

[Mike Young]

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

[basic]

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

[Mike Young]

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

[doctor__j]

FYI, that "phenomenon" is reported in bug 69803.

Comment 17

[doctor__j]

Another testcase: attachment 41480 [details]

Comment 18

[Tom Mraz]

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.

Comment 19

[Terri Preston]

Verified WFM linux build 2002012808