Closed Bug 35819 Opened 25 years ago Closed 23 years ago

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

Categories

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

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: a-huntwork, Assigned: pavlov)

References

(
URL
)

Details

(Whiteboard: [imglib])

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.
I can reproduce this on the 4.24.00 AM Netscape Commercial Linux build. Confirming. Good catch!
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
>>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
Status: NEW → ASSIGNED
Target Milestone: --- → M18
*** Bug 36370 has been marked as a duplicate of this bug. ***
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.
Target Milestone: M18 → Future
this work on a winNT platform but it hasn't tested it on the linux platform.
Blocks: 61527
QA Contact: elig → tpreston
Blocks: 66964
Blocks: 66966
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 ;)
This one isn't just Linux, i also get it on Windows Me. It affects the progress indicator bar at the bottom too.
All pnunn bugs reassigned to Pav, who is taking over the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
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: http://www.rpfuller.com/ugh.gif The gif also pauses when you open new windows.
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.
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?
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.
FYI, that "phenomenon" is reported in bug 69803.
Another testcase: attachment 41480 [details]
Blocks: 119597
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.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Verified WFM linux build 2002012808
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.