Regression: Viewport Walk Navigation : mouse escapes window if it moves too fast #102346

New Issue

ChameleonScales · 2022-11-08T09:56:01+01:00

ChameleonScales commented

2022-11-08 09:56:01 +01:00

System Information
Operating system:
Linux-5.10.0-19-amd64-x86_64-with-glibc2.31 64 Bits, Debian 11 XFCE
Graphics card: NVIDIA GeForce GTX 1660/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.141.03

Blender Version
Broken: versions:
3.4.0 Beta, branch: master, commit date: 2022-11-04 20:01, hash: bba6d28942
3.3.x
Worked: up until 3.2 (included)

Caused by 4c4e8cc926.

Short description of error
While in Walk navigation, if the Blender window doesn't take up all the screen's space (or if used on a dual screen), the mouse cursor will escape it if it moves too fast.
Note: this seems to be related to https://developer.blender.org/T86033. However, the Walk navigation was not affected until Blender 3.3, whereas Grabbing, scaling, etc... were affected since 2.79 if not before or forever.

Exact steps for others to reproduce the error

Shrink the Blender window to leave some space on the left side of the screen
From Factory settings: View > Navigation > Walk Navigation
Move the mouse fast to the left : it escapes the window

Video demonstration comparing between Blender 3.2 and 3.3:
Walk navigation mouse escaping bug0001-0385.mp4

**System Information** Operating system: Linux-5.10.0-19-amd64-x86_64-with-glibc2.31 64 Bits, Debian 11 XFCE Graphics card: NVIDIA GeForce GTX 1660/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.141.03 **Blender Version** Broken: versions: 3.4.0 Beta, branch: master, commit date: 2022-11-04 20:01, hash: `bba6d28942` 3.3.x Worked: up until 3.2 (included) Caused by 4c4e8cc926a672ac60692b3fb8c20249f9cae679. **Short description of error** While in Walk navigation, if the Blender window doesn't take up all the screen's space (or if used on a dual screen), the mouse cursor will escape it if it moves too fast. Note: this seems to be related to https://developer.blender.org/T86033. However, the Walk navigation was not affected until Blender 3.3, whereas Grabbing, scaling, etc... were affected since 2.79 if not before or forever. **Exact steps for others to reproduce the error** - Shrink the Blender window to leave some space on the left side of the screen - From Factory settings: View > Navigation > Walk Navigation - Move the mouse fast to the left : it escapes the window Video demonstration comparing between Blender 3.2 and 3.3: [Walk navigation mouse escaping bug0001-0385.mp4](https://archive.blender.org/developer/F13874636/Walk_navigation_mouse_escaping_bug0001-0385.mp4)

ChameleonScales commented

2022-11-08 09:56:01 +01:00

Added subscriber: @ChameleonScales

ChameleonScales changed title from ~~Viewport Walk Navifation : mouse escapes window if it moves too fast~~ to Viewport Walk Navigation : mouse escapes window if it moves too fast

2022-11-08 10:00:00 +01:00

Omar Emara commented

2022-11-08 13:30:20 +01:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-11-08 13:30:20 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Omar Emara commented

2022-11-08 13:30:20 +01:00

Seems similar to #86033 indeed and is a 3.3 regression. Let me know if you want me to bisect.

ChameleonScales commented

2022-11-08 14:14:49 +01:00

I personally don't know enough to bisect this (I have no C knowledge).
That said I'm thinking if this can be solved for the Walk navigation (which might be the only tool that ever got this working though I haven't tested others thoroughly), this may give pointers to solve it as well for Grab/Scale/Rotate.

I personally don't know enough to bisect this (I have no C knowledge). That said I'm thinking if this can be solved for the Walk navigation (which might be the only tool that ever got this working though I haven't tested others thoroughly), this may give pointers to solve it as well for Grab/Scale/Rotate.

Omar Emara commented

2022-11-08 14:21:22 +01:00

Sorry, that was directed to developers, I was just asking if finding the change that caused this issue would be helpful to them so that I can do it.

Omar Emara changed title from ~~Viewport Walk Navigation : mouse escapes window if it moves too fast~~ to Regression: Viewport Walk Navigation : mouse escapes window if it moves too fast

2022-11-08 14:21:34 +01:00

Julian Eisel commented

2022-11-08 15:18:45 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2022-11-08 15:18:45 +01:00

Bisecting this would be useful, yes.

Pratik Borhade commented

2022-11-08 17:08:57 +01:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2022-11-08 17:08:57 +01:00

Can confirm in windows OS so definitely not a platform specific(Linux) issue

Worked: up until 3.2

I can even reliably redo the issue in versions prior to 3.2. Unsure if this is a regression

Can confirm in windows OS so definitely not a platform specific(Linux) issue > Worked: up until 3.2 I can even reliably redo the issue in versions prior to 3.2. Unsure if this is a regression

ChameleonScales commented

2022-11-08 19:45:41 +01:00

I tested thoroughly on Linux and I confirm that it's impossible to get the mouse to escape the Blender window on 3.2.
Maybe Windows 11 introduced this problem? (the other bug report was posted before Win 11 was out)

I tested thoroughly on Linux and I confirm that it's impossible to get the mouse to escape the Blender window on 3.2. Maybe Windows 11 introduced this problem? (the other bug report was posted before Win 11 was out)

Omar Emara commented

2022-11-09 07:47:38 +01:00

Hmmm, I can indeed reproduce the issue before 3.2 on Linux, though it is harder to reproduce. So this doesn't seem to be a regression.

Omar Emara changed title from ~~Regression: Viewport Walk Navigation : mouse escapes window if it moves too fast~~ to Viewport Walk Navigation : mouse escapes window if it moves too fast

2022-11-09 07:47:46 +01:00

Omar Emara commented

2022-11-09 07:49:11 +01:00

Since some users can reproduce that even before 3.2, we should probably merge this to #86033, it seems you already added a note about that there.

Omar Emara commented

2022-11-09 07:49:58 +01:00

Closed as duplicate of #86033

Omar Emara closed this issue

2022-11-09 07:49:58 +01:00

ChameleonScales commented

2022-11-09 09:23:13 +01:00

I'm positive there is a regression but maybe it's also dependent on the window manager or even the OS. I use Debian 11 with XFCE.
On 3.2 I cranked my mouse speed to max level and moved it very fast many times. I really really can't get the navigation to break. In fact I know it's not possible because if I move really fast I see the cursor get out for a split second and immediately disappear. So something is preventing it from escaping for good.
With 3.3 I can even move the mouse very slow when the speed is cranked up and the cursor escapes for good, breaking the navigation.

I think it's worth reopening because the grabbing issue is definitely there on all versions since 2.8.

I'm positive there is a regression but maybe it's also dependent on the window manager or even the OS. I use Debian 11 with XFCE. On 3.2 I cranked my mouse speed to max level and moved it very fast many times. I really really can't get the navigation to break. In fact I know it's not possible because if I move really fast I see the cursor get out for a split second and immediately disappear. So something is preventing it from escaping for good. With 3.3 I can even move the mouse very slow when the speed is cranked up and the cursor escapes for good, breaking the navigation. I think it's worth reopening because the grabbing issue is definitely there on all versions since 2.8.

Omar Emara commented

2022-11-09 09:40:43 +01:00

@ChameleonScales I will consider bisecting anyways to find out why it became easier to escape in 3.3 and reopen in that case.
And to clarify, the task was merged, not closed, so it is still being tracked.

@ChameleonScales I will consider bisecting anyways to find out why it became easier to escape in 3.3 and reopen in that case. And to clarify, the task was merged, not closed, so it is still being tracked.

ChameleonScales commented

2022-11-09 11:06:04 +01:00

Ok. I added a video demonstration in the OP.

ChameleonScales commented

2022-11-09 12:06:23 +01:00

That said it's not the same bug. The Grab/Rotation/Scale one was there long before and btw I made a correction about that. I thought it appeared in 2.8 but turns out it was also there in 2.79, potentially before if not forever, so I'm not sure it should be merged with #86033 (I don't know how closely related it has to be for it to be merged).

Omar Emara commented

2022-11-10 09:38:57 +01:00

Changed status from 'Duplicate' to: 'Needs Triage'

Omar Emara reopened this issue

2022-11-10 09:38:57 +01:00

Omar Emara commented

2022-11-10 09:38:57 +01:00

Bisecting.

Omar Emara commented

2022-11-10 10:56:17 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Omar Emara commented

2022-11-10 10:56:17 +01:00

Added subscriber: @ideasman42

Omar Emara commented

2022-11-10 10:56:17 +01:00

Caused by 4c4e8cc926.

Caused by 4c4e8cc926a672ac60692b3fb8c20249f9cae679.

Omar Emara changed title from ~~Viewport Walk Navigation : mouse escapes window if it moves too fast~~ to Regression: Viewport Walk Navigation : mouse escapes window if it moves too fast

2022-11-10 10:56:49 +01:00

Campbell Barton was assigned by Julian Eisel

2022-11-16 17:02:28 +01:00

blender-admin commented

2022-11-19 10:57:59 +01:00

This issue was referenced by 9fd6dae793

This issue was referenced by 9fd6dae7939a65b67045749a0eadeb6864ded183

Campbell Barton commented

2022-11-19 11:12:49 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Campbell Barton closed this issue

2022-11-19 11:12:49 +01:00

Campbell Barton commented

2022-11-20 00:32:35 +01:00

When looking into a fix for this bug I investigated warping on-the-spot, however this is a bigger change and I wouldn't consider these safe for a bug-fix.

WIP patches D16557: [testing] GHOST/X11: Warp cursor on the spot & D16558: [testing] GHOST/WIN32: Warp cursor on the spot support warping on the spot, however both need some further investigation for reliably detecting when the cursor location has been reset.

When looking into a fix for this bug I investigated warping on-the-spot, however this is a bigger change and I wouldn't consider these safe for a bug-fix. WIP patches [D16557: [testing] GHOST/X11: Warp cursor on the spot](https://archive.blender.org/developer/D16557) & [D16558: [testing] GHOST/WIN32: Warp cursor on the spot](https://archive.blender.org/developer/D16558) support warping on the spot, however both need some further investigation for reliably detecting when the cursor location has been reset.

blender-admin commented

2022-12-14 11:02:53 +01:00

This issue was referenced by 5d73850dd4

This issue was referenced by 5d73850dd448e1f046c9ac44473efd23dd8cf33c

blender-admin commented

2022-12-14 11:02:53 +01:00

This issue was referenced by 230744d6fd

This issue was referenced by 230744d6fd96dcf5afe66a8f9b9f6f8bbe1f41bb

blender-admin commented

2022-12-15 01:57:00 +01:00

This issue was referenced by b87bcd3f8f

This issue was referenced by b87bcd3f8fe132b3cb99e5f17e77d8eca7f73d6f