Memory leak

This library does not clean out the memory it’s using. Before Chrome uses 116mb, after calling

canvasSize.maxArea({
        onError: (width, height) => {
            console.warn('canvas.maxArea Error:', width, height);
        },
        onSuccess: (width, height) => {
            console.log('canvas.maxArea - width: ' + width.toLocaleString() +
                'px, height: ' + height.toLocaleString() + 'px');
        }
    });

Chrome now uses 1.1GB and does not release that additional 1GB (!).

[jhildenbiddle]

Fixed in 1.0.4.

Thanks for filing the issue!

[jhildenbiddle]

Got it.

This library can answer the “how big a canvas can be in the client’s browser” question, but I think you’re going to run into issues rendering multiple large canvas elements (especially on memory-constrained and/or lower-end hardware with limited GPU acceleration).

I took a look at the zoom example so I have a better idea of what you’re referring to now.

The zoom approach shown in the demo tasks the browser with resizing the waveform visualization by rendering the waveform on a canvas at 100%, then adjusting the width of the canvas element to emulate zooming out. That works, but it has two major drawbacks: 1) it requires large canvas element which will consume a significant amount of memory, and 2) it requires multiple canvas elements for waveform visualizations that are larger then than largest canvas element supported by the browser (e.g a 20000px waveform will require two canvas elements in most modern browsers: 16384px + 3616px).

I can think of a few ways that would likely be more efficient, but without testing I can’t guarantee the results. The simplified explanation of all of them is this: use one canvas per waveform, make it only as large it needs to be in the DOM, and only render the part of the waveform that the user sees.

This article summarizes the idea and may provide some insights: http://joesul.li/van/2014/03/drawing-waveforms/