The web app uses too much CPU

[abcjjy]

I like the visualization and tooltips of this app. However, it the performance is not very well. On my mac book pro (chrome), it takes 100% cpu time. After turn off the "auto" option, it still takes 20-30% when idle. Can you fix this? Or simply port it to desktop? Or a mobile app?

[ttencate]

This is a legitimate issue; I've noticed it on my laptop as well. The problem is with the continuous rendering of the canvas element that draws the real-time spectrogram at the top. Even if I just clear it every frame without drawing anything, it still burns 100% CPU.

As a workaround, you can click that visualizer to disable it.

The real solution is probably to switch over to WebGL.

[marten]

Couldn't you stop the visualization automatically after (attack+sustain+decay) seconds?

[abcjjy]

I think the visualizer is a very important feature. And that is why I choose jfxr overother *fxrs.

According to my experience, WebGL is more performant than canvas. However, it still make the cpu burn if you always update it at 30 fps. Can you update visualizer only when sound is playing?

[ttencate]

Couldn't you stop the visualization automatically after (attack+sustain+decay) seconds?

There's a falloff after that, as it does some sort of IIR sliding average, but in principle, yes.

I just tried a very simple WebGL app. It also pulls CPU to 100%. Apparently this is normal. Blame your browser.

Meanwhile, I think I'll do what @marten said.

[mcanthony]

Canvas2D runs in GPU the same as WebGL so this will make no difference. Are we positive it is the visualizer causing "poor performance"? Your doing quite a lot of ScriptNode processing? or are you using AudioWorkers (if not then you will want to as SN will be deprecated) which will surely allow for faster rendering of the Audio. On my sluggish laptop with windows and too much running, it renders in 300ms usually and I consider that good. I will be playing with this project, feel free to hit me up if you want to get me up to speed.

[ttencate]

It's definitely the visualizer, because the high CPU disappears as soon as you turn it off.

Indeed render time for the sound effect itself isn't a huge problem. Longer sound effects (several seconds) do tend to make the UI a bit less responsive; that's tracked on #17.

(Offtopic - No ScriptNode processing is going on; the entire sample is pre-rendered into typed arrays. With ScriptProcessorNode it would be hard to refer to previous samples if they cross a buffer boundary.)