Fix: [Spectrogram] fix cropping and scaling issues

[jonom]

Short description

Resolves #3663, #3140

Implementation details

I've attempted to address some issues with the spectrogram rendering creating an image of the wrong height for the target container, causing it to be too tall or short to fill the area, and meaning the frequency labels do not line up with data in the image. There are some magic numbers in here (E.g. division by 2 or 4) I don't understand so appreciate if someone else can vet this!

(Marked as draft for now as I'm running tests locally but it's taking quite a while.)

Separate to this I've implemented some caching of the result of getFrequencies() as well as the rendered bitmaps as this can be quite slow, and for my use case we allow zooming in and out so I wanted to speed up the rendering. If this is something you'd like included I can add to this PR or open another one later.

How to test it

Screenshots

Checklist

• This PR is covered by e2e tests
• It introduces no breaking API changes

[katspaugh]

@jonom thanks for the PR! How did your tests go, did it solve those issues for you?

[jonom]

I'm not exactly sure how the e2e tests are supposed to be ran - after a while I worked out I could run them manually, but I didn't see snapshots to compare with expected results.

One thing I have found since is that setting sampleRate on the ws instance doesn't seem to affect rendering, except that if it's too small, the upper range of the spectrogram may be missing. So I've been setting it to 88200 and then it seems to always work 🤷‍♂️

[katspaugh]

I've commented out Spectrogram tests for now, they mysteriously always fail on GitHub Actions but work locally.