zoomWithWheel does not account for the delta value

[Foshkey]

Describe the bug

First of all, great library.

One slight issue with zoomWithWheel is this line:

    const wheel = delta < 0 ? 1 : -1

While we were implementing this library, I (using windows) got into a bit of a disagreement with our designer (using a mac) about the zoom speed. He was saying it was way too fast, while I was saying it felt just right.

That's when I discovered polling rates and what exactly deltaY means. In short: mac trackpads have a much higher polling rate, and therefore a lower delta value, and vice versa for my mouse wheel. If you want a consistent experience with zoomWithWheel, I advise taking the delta into consideration, as different mice/trackpads will have different polling rates and delta values.

We ended up doing the calculation ourselves, but if you're curious what the code is:

    const delta =
      event.deltaY === 0 && event.deltaX ? event.deltaX : event.deltaY;
    const scale = panzoom.getScale();
    const toScale = scale * Math.exp((delta * step * -1) / 300);
    const result = panzoom.zoom(toScale);

This resulted in a consistent experience and the designer and myself both agree that the zooming now feels right.

Your environment

• Version of panzoom
  • 4.4.2
• Browser and browser version
  • Edge Version 94.0.992.50 (Official build) (64-bit)

[timmywil]

Thanks for the suggestion! I'll look into this. Getting zoom rate right across all browsers/devices has constantly been in flux.

[jtran]

The above calculation worked well for me on a Mac with a trackpad.

Correct me if I'm wrong, but shouldn't you gate the above suggested calculation behind a check that event.deltaMode is 0? Presumably, the existence of event.deltaMode means that not all devices have a real pixel delta where such a calculation makes sense. For other values of deltaMode, maybe the current implementation with a step makes more sense.