631211 - Pages using Canvas consumes large amounts of CPU on Mac

Status: RESOLVED DUPLICATE of bug 540066

(Core :: Graphics, defect)

Description

[Mark Boas]

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.

Comment 1

[Mark Boas]

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.

Comment 2

[Paul Rouget [:paul]]

Is it a regression?

Comment 3

[Josh Matthews [:jdm]]

Confirmed the high CPU usage on just visiting the first link.

Comment 4

[Josh Matthews [:jdm]]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[David Humphrey (:humph)]

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.

Comment 9

[Grant Galitz]

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.

Comment 10

[Joe Drew (not getting mail)]

Given comment 8, let's call this a dupe.