mouse wheel interaction problems

[VolkerH]

Just reporting two issues I'm struggeling with, when interacting with the widget using the mouse wheel.

1. My Logitech mouse wheel has "click-stops". When zooming a volume rendering with itk, the amount of zooming between two click stops is way too large. (I need to check whether I can change sensitivity in the driver, however the sensitivity is just fine for all other software).
2. When scrolling through a jupyter notebook with the mouse wheel, the itk-widget "catches" the callback from the web-browser page scroll and starts zooming. This can be very annoying as one may be losing a carefully chosen viewpoint and/or produce a lot of lag. The behaviour depends on the exact position of the mouse cursor within the page.

I somehow have a feeling that there is no easy solution for these usability problems, but I didn't see them mentioned in any issue and thought they may be worth documenting.

[thewtex]

@VolkerH thanks for the report. @agirault any thoughts?

[agirault]

Those two issues seem to be vtk-js related. Which version of vtk-js is being used? Can we confirm this by creating a minimal example reproducing the issue then post it on https://github.com/Kitware/vtk-js/issues ? (Could use Glitch for this, unless you have other suggestions @thewtex )

1. We used to have an issue with the scroll delta and the mouse wheel, however, they were addressed with:

• https://github.com/Kitware/vtk-js/pull/658: uniformizing mouse wheel deltas
• https://github.com/Kitware/vtk-js/pull/1036: fixing up stepping issue in MouseRangeManipulator I don't think the later is used for volume rendering though. @VolkerH: is that only for volume rendering, or would that be the same with a 3d model? How do you setup the zoom interaction?

2. I believe that by design, the context will capture the event if you are above the canvas. @floryst any suggestion?

[thewtex]

Thanks for the expert input @agirault !

Re 1.: we updated vtk.js in itk-jupyter-widgets 0.16.2, released two days ago -- @VolkerH could you please test that version?

Re 2. I wonder if we can disable zoom until the mouse dwells in the div for a period of time...

[agirault]

2. ~~There might be a way to ignore it if it wasn't started within the context, but I couldn't find it. However, this example by mozilla allows you to scroll in the page without unzooming the view as long as you don't start scrolling in it: https://developer.mozilla.org/en-US/docs/Web/API/Element/wheel_event. Maybe there is something we could use to do the same in vtk-js?~~ cc: @jourdain @floryst

Nevermind, the vtk-js context works the same way: it will only scroll if you start the wheel event inside the context. The problem occurs when your canvas is big and you continuously scroll in the page, so the chance of a scroll starting inside the canvas is high. The only solution I can think of is to have a button to enable/disable the zoom interactor in a corner of your render window.

[VolkerH]

Kitware/vtk-js#1036: fixing up stepping issue in MouseRangeManipulator I don't think the later is used for volume rendering though. @VolkerH: is that only for volume rendering, or would that be the same with a 3d model? How do you setup the zoom interaction?

I have only tried volume rendering (or 2D images), I don't have any surfaces. I don't set up anything, just using defaults.

The problem occurs when your canvas is big and you continuously scroll in the page, so the chance of a scroll starting inside the canvas is high

This is the case when I use jupyter notebooks. I typically have the mouse cursor over some cell when using a jupyter notebook (as I would have been selecting/editing a cell) and then I start scrolling with the wheel to look at a different cell. So the mouse cursor remains in the general area of the cells and therefore gets caught with scrolling. I would have to move the mouse cursor to the sides of the screen before starting mouse wheel scrolling, but this is not intuitive.

Re 2. I wonder if we can disable zoom until the mouse dwells in the div for a period of time...

I thought of this as well. It is the only idea I can come up with but then that might stump some people as well.