How relevant is multi-canvas these days?

[katspaugh]

The maximum canvas size in most browsers is huge

According to MDN, major browsers seem to have a huge headroom when it comes to the maximum canvas size.

Some napkin calculations

If we take the minimum of 268,435,456 pixels (Chrome and Safari) – 268 millions! – and assume the typical height of a waveform is 400 px (to be generous), this gives us ~671k pixels of width.
If we assume a zoom level of 100 px per second, this gives us approximately 2 hours of audio.
That should be more than enough for most waveforms, shouldn't it?

Opimizations for the single canvas

In my experiments, I found that it's not necessary to render the height in a double resolution for hi-res screens. Doubling the width alone already results in a sharp image.
If we keep the height at x1, it will double the available canvas real estate.

[thijstriemstra]

If we assume a zoom level of 100 px per second, this gives us approximately 2 hours of audio.
That should be more than enough for most waveforms, shouldn't it?

This feels like a step backwards.

[katspaugh]

I understand the sentiment, but can you please elaborate on what are the rational reasons to want more than a 268-million-pixel rendering in the browser?

[entonbiba]

@katspaugh might make sense to do the multi canvas option if it exceeds let's say 20 minutes of audio automatically while anything less sticks to a single one.

[katspaugh]

That would require us to still have and maintain that code, wouldn't it? It's not about runtime dependencies, my concern is about the code complexity and size.
In wavesurfer.ts (the next version), we'd have to port the multi-canvas, so I'm wondering if it's needed in the first place.

[sundayz]

During the meeting I had with katspaugh last week we discussed the new API, and how we should make the renderer an interface. If we were to remove the MultiCanvas renderer, it could be re-implemented as a 3rd party plugin. We just have something like this:

interface Renderer {
    drawBar(height: number): void;
    getImage(): Promise<number[]>;
    clearCanvas(): void;
    // ... others methods here that are required for a Renderer to work (i.e. draw a waveform)
}

We can supply a basic Canvas2DRenderer, and the community can write other renderers, for example using WebGL, using SVGs, using multiple canvases, and any other way that you might want to draw a waveform. The WaveSurfer core library just calls the methods on the renderer object you pass in when you initialize it.

[katspaugh]

That's a solid idea. I think it's a good approach to the architecture of the lib, and we should do it either way.

However, I'd still like to understand if multi-canvas is something the majority of users want, or it's just for some edge-case scenarios like, I don't know, super-long podcasts.

The PR that introduced it was made in 2016, and it links to a couple bug reports that bumped into the canvas limits.

One of the test cases in that PR was a 500k-pixel-wide waveform. With the current canvas limits, it would still fit on a single canvas with the height of 536 pixels.

I'm now convinced that this approach is an overkill with the modern limits, which are probably much higher than in 2016.
I'm not going to propose to delete multi-canvas from the current wavesurfer version, but I wouldn't pursue that in wavesurfer.ts.
It might make sense as a 3rd-party renderer indeed.

[katspaugh]

It turns out multi-canvas is still relevant, because although the total size of the canvas can be millions of pixels, the width is capped at ~32k pixels. So I've implemented multi-canvas in the new wavesurfer version as well. It also comes with performance improvements, because the canvases are rendered each with a small delay.