Closed Bug 786585 Opened 12 years ago Closed 10 years ago

Moving mouse inside maze solver makes all animations stop in other tabs

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
18 Branch
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mayankleoboy1, Unassigned)

References

Details

Attachments

(1 file)

about support.txt
3.97 KB, text/plain
Details
Attached file about support.txt —
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20120828030555 Steps to reproduce: STR : 1. Open the maze solver page http://ie.microsoft.com/testdrive/Performance/MazeSolver/Default.html 2. In a new window, open a animated GIF. Eg. : http://upload.wikimedia.org/wikipedia/commons/thumb/2/2c/Rotating_earth_%28large%29.gif/200px-Rotating_earth_%28large%29.gif 3. In the maze solver window, select a 40x40 maze. 4. DONT press the "solve" button. 5. Just put the mouse pointer inside the maze. Watch the animation slow 6. Move the pointer inside the maze. Animation stops completely. Actual results: Animation stops completely. Expected results: There should not be any effect on the animations. attaching the about support file.
Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/18.0 Firefox/18.0 (20120829030520) When moving the mouse pointer inside the maze, the animation got slow and jerky. It started working fine after I got the mouse pointer out of the maze though.
Status: UNCONFIRMED → NEW
Component: Untriaged → Graphics
Ever confirmed: true
Product: Firefox → Core
Hardware: x86_64 → All
attaching profile with a GIF animation open in another window. http://people.mozilla.com/~bgirard/cleopatra/?report=a45549b53db159caebc14777e09bcee8a1f0861c The jerkiness increases with the complexity of the maze. A 40x40 maze completely halts all the animations and HTML5 videos in other tabs. A 30x30 only slows down them.
Is this behavior a regression?
I think this resulted most probably from DLBI. AFAIK, DLBI has some optimisations for the 30x30 maze.So moving mouse inside it causes only a minor slowdown. But in both 20x20 and 40x40, the slowing is severe. If you keep on moving the mouse for ~10-12 seconds, the browser window frame flashes(disappears and appears) and the nightly icon in windows taskbar goes through the "window closing" animation.
Would you be willing to verify that hypothesis by testing nightlies before and after dlbi landed? For what it's worth, dlbi has nothing in it specific to the 30x30 maze here.
That depends on the total data to be downloaded. I have a cap on download :( .. Also, whats is the method to do this ? FWIW, i cant reproduce this on FF15
The easiest way is probably to try the 2012-09-28 nightly and the 2012-09-29 nightly. dlbi is in the latter, but not the former, I believe.
Yes, for the former. You want 09-29 for the latter.
1. I can reproduce this on the build to the first link. So my hypothesis is wrong. 2. Another way to check for this bug is to open the task manager and start moving the mouse. Note that the CPU usage will become 100%. (25% for quad core). Which shouldnt be as the maze is _not_ being solved. Only the mouse is moving. 3. Another way is to start the profiler and move the mouse. While the mouse is moving, the "green FPS/time thread graph" in the profiler will stop moving completely.
> 1. I can reproduce this on the build to the first link. So my hypothesis is wrong. OK. How big is your download cap? Is doing a bisect on nightlies back to Firefox 15 (2012-06-05, so about 4 months, so about 8 nightlies to download) feasible? > 2. Another way to check for this bug is to open the task manager and start moving the > mouse. I can't reproduce this, on Mac. :(
8 nightlies ~160MB is OK. Have you been able to reproduce this at all? just did a random check on 10september build from here : http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-09-10-03-05-24-mozilla-central/firefox-18.0a1.en-US.win32.installer.exe can repro on this too. And please give me the steps on how to bisect.
> Have you been able to reproduce this at all? Not so far, no. > And please give me the steps on how to bisect. http://harthur.github.com/mozregression/ will do it automatically. If you want to minimize downloading, hence to it by hand, then start with downloading the 2012-06-05 build. If that does not show the problem, then download a build from about halfway between that and 2012-10-10 (so for example 2012-07-22) and test there. Depending on whether that shows the problem or not, decide what next build to download, etc.
in this : http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/14.0b8-candidates/build1/win32/en-US/Firefox%20Setup%2014.0b8.exe the GIF is not slowed down. But there is high CPU usage. 1% on moving mouse outside the box, 22% on moving mouse inside the box.
Will high CPU use be a part of this bug? or this bug is to solve animation pauses only ?
I would focus on the animation pauses, unless the high cpu is also a recent regression.
i think animation pauses will be present in nightlies only because of additional work of of collecting the profiling pointers. On the 14.08b i tested above, the CPU use is ~22%. Add another 3-4% for collecting pointers, and the complete processor is bogged down, making the animation pause.
Hi Boris. 16.0b1 (16 beta 1) is the first version that shows this _complete_ stopping of animation. Release 15 version does not show complete stopping. I also checked with Release version 4. It shows 90% CPU usage when moving mouse inside the 40x04 maze. So high CPU usage is an old bug. Please let me know if i can help further.
Are you able to narrow down the complete stopping to a particular nightly using the regression finding script I linked to in comment 13?
the regression is between 15 release and 16 beta 1(of 28 august build). I am not sure how to progress further with this info and the regression script,which works on nightlies..
15 release should correspond to nightlies from around 2012-06-05. 16 beta 1 should correspond to nightlies from around 2012-07-16, I think, but maybe as late as 2012-08-27 if thing got backported. Does that help?
Last good nightly: 2012-07-26 First bad nightly: 2012-07-27 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7065b767f30d&tochange=8b96a33ecbd2
Yeah, none of those look directly related, but neither does anything else from that pushlog.... Thank you for finding the regression range!
Depends on: 816430
doesnt happen anymore
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: