Visualization uses a lot of CPU

[lnostdal]

Visualization uses a lot of CPU

[auroranockert]

Yes, most of the CPU usage is from the visualization, just the audio pipeline takes about 8% of one core on my 2.4GHz Core 2 Duo Macbook Pro using Firefox.

[lnostdal]

Yep, about the same here. This kind of ruins the demo though; at least initially. Perhaps it could/should be removed? Anyway, thanks for this; the idea of lossless via the browser is very cool ... :)

[auroranockert]

Maybe, we kind of rushed the demo etc. The codec was finished and we didn't want to delay the release.

We're probably going to improve it for our next release. Most of the CPU is spent in drawing, so there is probably a lot of room for improvement.

[nddrylliog]

Yep, about the same here. This kind of ruins the demo though; at least initially. Perhaps it could/should be removed? Anyway, thanks for this; the idea of lossless via the browser is very cool ... :)

@lnostdal You can disable the visualization by clicking on it. Doesn't use any CPU when inactive, so you can (unscientifically) measure the real CPU usage of audio decoding.

[lnostdal]

On Fri, Dec 23, 2011 at 5:05 PM, Amos Wenger <
[email protected]

wrote:

Yep, about the same here. This kind of ruins the demo though; at least
initially. Perhaps it could/should be removed? Anyway, thanks for this; the
idea of lossless via the browser is very cool ... :)

@lnostdal You can disable the visualization by clicking on it. Doesn't use
any CPU when inactive, so you can (unscientifically) measure the real CPU
usage of audio decoding.

That's odd. I'm sure I tried just that before posting here, but indeed that
works.

[jussi-kalliokoski]

You can get the best effect of how cheap the decoding is compared to the UI by first disabling the visualization (it also disables the FFT calculation that way) and going into another tab (doesn't work in Firefox 5 and 8). We'll probably use a WebGL visualization in the future, lifting around 70% of the current CPU load.

But a funny thing is that even the fairly simple UI (excluding the visualization) uses a lot of CPU compared to the actual decoding, because of the DOM manipulation and redrawing of elements (the seek bar, the browser probably renders some surroundings while at it as well).

However, imho, this is an interesting proof that JavaScript is fast (enough), but it's just the all the layers like DOM and canvas slowing things down.