Closed
Bug 636755
Opened 13 years ago
Closed 10 years ago
Slight slowdown with setInterval when system volume is changed
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: grantgalitz, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre Firefox seems to delay setInterval badly for a duration of a half a second a second after changing the volume up or down on Snow Leopard 10.6.6. Not a bad bug at all, but quite a mysterious one indeed. I work around the bug by producing extra audio samples to make sure the audio stays gapless during the slowdown, so I could care less for now. Reproducible: Always Steps to Reproduce: 1. Load a .gb or .gbc ROM file into the emulator. 2. Make sure audio in on. 3. Change your volume once the game is running. Actual Results: Weird slight slowdown that occurs one second after changing the volume and lasts for about a second. Expected Results: No slowdown. Happens with any GameBoy or GameBoy Color ROM binary as far as I know.
Reporter | ||
Updated•13 years ago
|
Component: General → JavaScript Engine
Summary: Slight Slowdown when system volume is changed → Slight Slowdown with setInterval when system volume is changed
Reporter | ||
Updated•13 years ago
|
Summary: Slight Slowdown with setInterval when system volume is changed → Slight slowdown with setInterval when system volume is changed
Updated•13 years ago
|
Assignee: nobody → general
QA Contact: general → general
Reporter | ||
Updated•13 years ago
|
Reporter | ||
Comment 1•13 years ago
|
||
I changed the URL above to a page that automatically loads a ROM in. http://www.grantgalitz.org/gameboy/ is the page that has the user load in a ROM.
Comment 2•13 years ago
|
||
I can't reproduce on the URL in the url field. Is that deploying the workaround you mention in comment 0, or does it actually show the bug for you?
Reporter | ||
Comment 3•13 years ago
|
||
That workaround is actually a feature that kicks in when firefox is max'd out and CPU usage is at 100%. The weird thing about this bug is that CPU usage *goes down* when the volume changes, causing the slowdown.
Reporter | ||
Comment 4•13 years ago
|
||
It deploys the workaround, but you'll notice the ROM goes in slo-mo (sounds that way too) for a second and you'll notice a drop in CPU usage by approx. 10% (that's what the diff was on my macbook pro.).
Comment 5•13 years ago
|
||
> but you'll notice the ROM goes in slo-mo (sounds that way too)
I don't see that effect.
Reporter | ||
Comment 6•13 years ago
|
||
Here are my specs to see if this helps one bit: System Version: Mac OS X 10.6.6 (10J567) Kernel Version: Darwin 10.6.0 Model Name: MacBook Pro Model Identifier: MacBookPro7,1 Processor Name: Intel Core 2 Duo Processor Speed: 2.4 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache: 3 MB Memory: 4 GB Bus Speed: 1.07 GHz
Reporter | ||
Comment 7•13 years ago
|
||
I'll get a better testcase that has a more stable CPU usage over time, so the drop is clearer. Yeah, the emulation doesn't stop, but there's definitely a slowdown at least on my comp that seems to stem from setInterval timing being wrong or something (Like as if there's another process holding it up from working normally). I want to be clear and say this is not important, but a very unusual thing to have going on indeed.
Comment 8•13 years ago
|
||
> but there's definitely a slowdown at least on my comp
My point is that I do NOT see that happening at all over here.
I'd love to see a testcase that actually shows the problem!
Reporter | ||
Comment 9•13 years ago
|
||
A more stable test ROM in terms of average CPU usage over time: http://www.grantgalitz.org/gtfo/SMB_TEST/index.php Any drop in CPU usage should be more easily discernible with that ROM, since it holds its average load on the CPU better.
Reporter | ||
Updated•13 years ago
|
Severity: minor → trivial
Comment 10•13 years ago
|
||
Url in comment 9 is 404.
Reporter | ||
Comment 11•13 years ago
|
||
Sorry about that, I did some directory cleaning. Try http://grantgalitz.org/shantae/
Comment 12•13 years ago
|
||
Can't reproduce there either....
Reporter | ||
Comment 13•13 years ago
|
||
Happens with other mac os x programs. It seems Mac OS X interferes with timing of programs in this case in general. Not an exclusive bug to Firefox. Weird interruption from the system though.
Reporter | ||
Comment 14•13 years ago
|
||
The test URL is back up. Took down these other links again. Damn, I really should stop deleting folders all the time on my server...
Reporter | ||
Comment 15•13 years ago
|
||
I'd recommend this as a won't fix just because it seems like an obscure OS bug that's hard to even tell that it even exists.
Reporter | ||
Comment 16•12 years ago
|
||
Still happens with the nightly and stable
Reporter | ||
Updated•11 years ago
|
Reporter | ||
Comment 17•11 years ago
|
||
Still happens, but it seems it's the OS rather mucking with stuff. The OS reduces timer resolution on-demand messing up firefox timer logic.
Comment 18•10 years ago
|
||
(In reply to Grant Galitz from comment #17) > Still happens, but it seems it's the OS rather mucking with stuff. The OS > reduces timer resolution on-demand messing up firefox timer logic. invalid based on this comment
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•