Fix camera 3D absolute rotation bug

[brisvag]

Fixes/Closes

Closes #5725

Description

We were ignoring mouse release events.

Type of change

• Bug-fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

[jni]

Ha! Nice! I'd gone with my quick fix (just use arcball) and was about to open a PR. This is better. 😃 (Though I think zooming is less useful in 3D anyway, because you can't change the center of the zoom.)

[brisvag]

I did not review the previous PR, so I don't know exactly what was the purpose of these lines. At least this fixes the problem, but someone who reviewed and understood should take a look and make sure (for example) that there's no other events we're ignoring unnecessarily. @jni @alisterburt

[jni]

I think the point is to not ignore the mouse wheel if zoom is active and not ignore relevant mouse events if pan is active. I did a git grep event.type in vispy and didn't find other mouse events, but the fly camera uses keyboard events that we would mask if we used it in this way:

vispy/scene/cameras/fly.py:            if event.type == 'key_release':
vispy/scene/cameras/fly.py:        if event.type == 'mouse_wheel':
vispy/scene/cameras/fly.py:        if event.type == 'mouse_press':
vispy/scene/cameras/fly.py:        if event.type == 'mouse_release':
vispy/scene/cameras/fly.py:        if event.type == 'mouse_move':
vispy/scene/cameras/magnify.py:        if event.type == 'mouse_wheel':
vispy/scene/cameras/panzoom.py:        if event.type == 'mouse_wheel':
vispy/scene/cameras/panzoom.py:        elif event.type == 'mouse_move':
vispy/scene/cameras/panzoom.py:        elif event.type == 'mouse_press':
vispy/scene/cameras/perspective.py:        if event.type == 'mouse_wheel':
vispy/scene/cameras/perspective.py:        if event.type == 'mouse_release':
vispy/scene/cameras/perspective.py:        elif event.type == 'mouse_press':
vispy/scene/cameras/perspective.py:        elif event.type == 'mouse_move':

Something to watch out for... I think @kevinyamauchi and @alisterburt played around with the fly camera in the Dresden hackathon?

[brisvag]

I think we're fine, this function is only handling mouse events, right? viewbox_mouse_event()

[jni]

Hey look just because your mouse doesn't have a full-size keyboard on it... 😜

[codecov]

Codecov Report

Merging #5726 (c133f0a) into main (4f77ae8) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #5726   +/-   ##
=======================================
  Coverage   89.83%   89.84%           
=======================================
  Files         608      608           
  Lines       51856    51856           
=======================================
+ Hits        46587    46592    +5     
+ Misses       5269     5264    -5     

Impacted Files	Coverage Δ
napari/_vispy/camera.py	93.89% <ø> (ø)

... and 4 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[Czaki]

Instead of managing allow list maybe revert logic of this if and use deny list for block calling super implementation?

[brisvag]

Not sure how to reverse this in a sensible way... Something like this?

if 
	(not self.mouse_zoom and event.type == 'mouse_wheel')
	or (not self.mouse_pan and event.type in ('mouse_move', 'mouse_press', 'mouse_release')
):
	event.handled = False
else:
	super().viewbox_mouse_event(event)

[Czaki]

yes, but this logical clause not looking like full reverse

[jni]

I just played around with other 3D mouse operations in this PR (shift+drag = move rotation centre, shift+right-click-drag = perspective projection) and they work fine:

(I call this composition "inside the asteroid field" 😜)

so I suggest we merge this as is for now, and iterate in future PRs if we encounter issues. I think it's important that our 3D camera on main gets fixed ASAP.

[brisvag]

Now that I think about it, in 3D we probably only want to block events that have no modifier (rotate) or exactly shift (pan), and let through everything else. And maybe distringuish between pan and rotate...

Or maybe we should just revert the change to 3D cameras ^^'

[jni]

In line with my comment above, I'm going to merge this to fix main, we can continue to iterate on the conditions in future PRs if we discover more issues with this approach! 🙏

[Czaki]

@jni If you think that something should be improved on follow-up PR then please open a proper followup issue on merge of PR to not lost knowledge.