User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11pre) Gecko/20110202 Firefox/4.0b11pre Loading pages that use Audio Data API and Canvas seem to consume a lot of CPU. Probably related - opening further tabs during the course of the day will eventually cause Firefox to hang (beachball) and the rest of the OS to react very slowly. Sorry I can't be more specific than this. Reproducible: Always Steps to Reproduce: 1.Open Firefox - check CPU usage 2.Visit http://weare.buildingsky.net/processing/dsp.js/examples/fft.html 3.Check CPU usage. NOTE no requirement to start the audio. Actual Results: CPU usage for the Minefield process reached 102% when visiting the page containing Audio Data API and canvas functionality. Expected Results: CPU usage to rise, but to an acceptable level. 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 Upon opening http://niiden.com/simplesynth/simplesynth.html in another tab and leaving for 30 mins, observed the following errors : A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: resource://gre/components/nsPrompter.js:68 A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://niiden.com/simplesynth/simplesynth.js:13 Also the UI becomes sluggish and pops can be heard sometimes when switching tabs or moving the mouse cursor rapidly. Again apologies for the wooliness of this bug report, difficult to link a particular page with the browser eventually hanging.
On submitting this bug the browser hung. The Minefield process was no longer responding and CPU usage of that process fell to 15%. The rest of the OS became sluggish. Killing the minefield process restored the system to normal.
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio
Is it a regression?
Confirmed the high CPU usage on just visiting the first link.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Looks like all of the time goes into running timer callbacks, and specifically 44.02% of time spent in code called from the MethodJIT: nsCanvasRenderingContext2D::Stroke: 17.04% | nsCanvasRenderingContext2D::DrawPath: 9.39% | nsCanvasRenderingContext2D::Redraw: 7.41% | | nsHTMLCanvasElement::InvalidateFrame: 7.25% DisabledSetPropC<0>: 7.39% js::mjit::stubs::CallName: 2.72% js::mjit::stubs::Add: 2.05% followed by a few canvas quickstub operations that each take about 1.40% - 1.95%.
> CPU usage to rise, but to an acceptable level. What's an "acceptable level"? The page for some reason draws to a canvas every 10ms. If it takes about 10ms to do whatever it's doing (drawing, js, etc), then you'll get 100% cpu usage. Or more, if we're parallelizing the work.
So on my Mac, I see a breakdown like so: 40% stroke on canvas (this is all in cairo code; about half is CoreGraphics path drawing and the rest is cairo state setup/restore). 25% painting 10% running mjit-generated code. 5% setting style on canvas 4% fillRect on canvas 2% string concatenation in JS 2% closePath on canvas 1% moveTo on canvas So this looks like your typical "canvas is slow on Mac" testcase; we have bugs on that....
Summary: Pages using Web Audio API and Canvas consume large amounts of CPU → Pages using Canvas consumes large amounts of CPU on Mac
In particular, note that you can _always_ make canvas saturate the CPU by just making your path more complicated.... So I don't think it makes sense to talk about "acceptable level" here; what makes sense to talk about are particular hotspots or measured slowdown against other software trying to do the same thing.
This isn't really audio related--the fft calculations are taking no time. I'd say this is bug 540066 and similar. CC'ing Corban, who wrote it, for info. Corban, are you using are latest pjs? We use mozRequestAnimationFrame now.
Component: Video/Audio → Graphics
QA Contact: video.audio → thebes
Not always true even if true for your case. An example would be how the webkit and presto engines take up to 5x more CPU to process putImageData on my GameBoy Color emulator (To the point where a browser like Google Chrome noms up 2x more CPU with its own internal rendering than with the JS execution (Also to mention: This is also true even with hardware acceleration in chrome. xD).) than in Firefox.
Given comment 8, let's call this a dupe.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 540066
You need to log in before you can comment on or make changes to this bug.