Fix: [Zoom] Performance improvements (especially w/ trackpad zoom)

[ffxsam]

Short description

Zooming with a trackpad was causing huge CPU spikes due to constant redraws. This PR imposes rate limiting via a delta threshold before actually redrawing the waveform.

Implementation details

Debounce & throttle were not appropriate here, as we don't necessarily want to throttle the events, we just want to ignore the "in-between" delta values and have a more notched zoom (a la Adobe Audition).

How to test it

Test using any trackpad with smooth scrolling (i.e. lots of event firing when scrolling).

Checklist

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

[ffxsam]

Still a work-in-progress. Standard mouse wheeling is a bit wonky now (doesn't always zoom). Delta accumulation logic needs tweaks.

Also, unsure if this is a breaking API change. IMO, the default behavior should be the zoom detents (deltaThreshold of 10). Users can have smooth zooming by setting this to 0.

Open to any ideas, changes, etc. This is just a start!

[ffxsam]

This might help explain why throttling wasn't the right approach:

In Audition, you can scroll as quickly as you want, but it's a stepped zoom rather than a fluid one. Also, maybe a deltaThreshold setting is too in-the-weeds, and we just need a simpler stepZoom boolean.

Audition.mp4

[katspaugh]

Here it can probably be just set to 0?

[ffxsam]

I'm gonna rework some of this. I'll mark the PR as ready for review once I think it's in a good spot.

[ffxsam]

Ok, just setting it to 0 seems to have fixed ignored mouse wheel movements.

The thing is, all mice are different, and some of them may have smaller delta jumps with each wheel notch. Tested on a Logitech Lift and a Logitech MX Master 3S (with smooth wheel enabled). Both had similar deltas (see below), but that's likely because they're both Logitech. 😉 In other words, some mice might have to scroll two notches before the zoom method is called. Not sure if this is a big deal though.

[katspaugh]

Thanks! 👍

[ffxsam]

Sure, thanks for the review!

Thoughts on the option itself? deltaThreshold provides more control for people to tweak it. Or we could just figure a value of 10 is good, and have stepZoom: boolean and default it to true.

[katspaugh]

So to clarify, you ideally want the waveform to re-render every time the mouse wheel clicks, but we cannot count clicks, only a (pixel?) delta?

Looking at this MDN article, it looks like we can only see what mode the mouse wheel is in (scrolling per page, per line or per pixel).

And of course touchpads and trackballs don't have notches at all...

So I think 10 is a sensible default, especially if your two mice are around that ballbark.

@HoodyHuo @cmorbitzer good with you?

[ffxsam]

Right. Too many re-renders = bad news for those on lighter-weight computers. Step zoom is just the safer route.

Even when I compare Adobe Audition vs. iZotope RX with trackpad zoom, RX has smooth zoom, and my CPU usage jumps to 150-200+. With Audition (step zoom), my computer doesn't even get its heart rate going. 😁

[cmorbitzer]

LGTM

I don't have an opinion on performance, but 10 felt choppy to me as a user, where 5 felt seamless enough. Do we get much of the same resource benefit by setting the threshold to 5?

[ffxsam]

A setting of 5 had more spikes for me (on a Mac Studio), but still better than totally smooth zoom. Maybe we default delta threshold to 5? I can test in a bit, and I'd like to update the docs a bit to explain this setting better.

[ffxsam]

Yep, 5 is good. Not as good as 10, but a good middle ground. Just updated the code, and I think the description for this setting will do.

[katspaugh]

Thanks!

[bernardwiesner]

@ffxsam Even setting the deltaThreshold to 50, when I scroll quickly on a big waveform, page suddenly crashes.

Could we not use a throttling instead? I mean user scrolls very quickly, but we only re-draw once after the scroll is over. It would not be as fluid but more stable.

[ffxsam]

@bernardwiesner Hey Bernard! I'm honestly not sure. If we used throttle, that would mean that scroll events would have no visible effect until the user stopped scrolling, which is not ideal.

If you're experiencing any kind of bug or performance issue, please feel free to open a new issue.

Thanks!