Huge difference in scroll speed between firefox and chrome about svg.panzoom.js

[Fuzzyma]

Feel free to create a PR to fix this issue. There also was a different issue (in the chat), that in chrome the event fires far more often than in Firefox. It would make sense if chrome fires it for every px instead of line. What about figuring out how high a DOM_DELTA_LINE is in Firefox and multiply by that amount? Feels more stable...

[jonenst]

As per https://stackoverflow.com/questions/20110224/what-is-the-height-of-a-line-in-a-wheel-event-deltamode-dom-delta-line , computing the exact pixel height is difficult :( But for my case of using zoom, I don't need it to be pixel accurate, I just don't want it to be unusable. Would you accept a simple PR multiplying by 17 just to make it usable again ?

[Fuzzyma]

The thing is: I used panzoom in both browsers and never had an issue with scroll speed. Is this something which is only present on linux?

[jonenst]

according to w3c/uievents#181 (comment) it should be slow with firefox on all platforms..

Maybe you haven't seen the problem because you only changed recently in 01a627a Date: Wed Jan 29 07:01:21 2020 +0100 (release 2.1.0)

-      let lvl = this.zoom() - zoomFactor * ev.deltaY / Math.abs(ev.deltaY)
+      let lvl = Math.pow(1 + zoomFactor, (-1) * ev.deltaY / 100) * this.zoom()

before you had "ev.deltaY / Math.abs(ev.deltaY)" which was always +1 or -1
now you use ev.deltaY directly

[Fuzzyma]

No, actually I tried it with that change. But I could be wrong. Do you mind creating a codepen with a minimal example so I can look into the issue?

[jonenst]

Sure, here you go: https://codepen.io/jonenst/pen/PoPbxrg
I used
https://unpkg.com/@svgdotjs/[email protected]/dist/svg.js
https://unpkg.com/@svgdotjs/[email protected]/dist/svg.panzoom.js

and here's a ®high quality gif ™ of it (on the right chrome zooming, on the left firefox)

cheers,
Jon

[Fuzzyma]

jep confirmed - that sucks...
If the events indeed fire different number of times we have to go with your solution. But if they fire about the same amount, we can just use +-1 again instead of the delta

[jonenst]

The nice thing with using the real value of deltaY is that you get slow/fast scrolling with a touchpad depending on how fast you swipe.
Also, if we use something like

(if deltaMode == 1) {
  deltaY = deltaY * PIXELS_PER_LINE
}

Then it will only affect the firefox broken case. Make PIXELS_PER_LINE configurable and it should work for everyone ?

I don't know how many events are fired but I don't think going back to the +-1 is the best option.

By the way, if you have a windows machine, maybe you can try to look what happens when the browser uses deltaMode=2 ( https://i.stack.imgur.com/3AtUg.png ), if zooming is fixable in this mode or not.

Cheers,
Jon

[Fuzzyma]

That could work. I hereby declare to not support deltaMode=2. This is just nonesense...

[jonenst]

Do you want me to do the PR ? You might know better how to make the PIXELS_PER_LINE value configurable

[Fuzzyma]

just add an option. It should be quite obvious were to put it :)

[trusktr]

There are too many inconsistencies with delta values across browsers, even today. Related web spec issue:

• w3c/uievents#181