Mouse wrapping causes erratic movement #89399

New Issue

Andrew · 2021-06-24T01:27:08+02:00

Andrew commented

2021-06-24 01:27:08 +02:00

System Information
Operating system: Windows 10, 20H2
Graphics card: Nvidia GTX 1650

Blender Version
Broken: 2.91 - 2.93
Worked: 2.79 (That I know of)

Short description of error
I first noted this issue on https://blender.stackexchange.com/q/228330

Sometimes, when the cursor wraps around the screen, whatever I am editing will jump drastically in location, scale, etc. I was best able to capture this phenomenon with scaling a cube, but it happens for literally everything; it's not even limited to the 3D Viewport.

Note how the cube jumps in scale when the cursor wraps around the edge. That's not a bug in the gif; that's what actually happening.

I have encountered this issue on multiple computers with multiple mice. I first encountered it in Blender 2.91, but it is possible it has existed longer than that.

Exact steps for others to reproduce the error
Based on the default startup.

Select the default cube
Hit s for scale
Drag mouse past screen border so it wraps around. Drag it back and forth a couple times and the size should jump.

**System Information** Operating system: Windows 10, 20H2 Graphics card: Nvidia GTX 1650 **Blender Version** Broken: 2.91 - 2.93 Worked: 2.79 (That I know of) **Short description of error** I first noted this issue on https://blender.stackexchange.com/q/228330 Sometimes, when the cursor wraps around the screen, whatever I am editing will jump drastically in location, scale, etc. I was best able to capture this phenomenon with scaling a cube, but it happens for literally everything; it's not even limited to the 3D Viewport. ![MouseWrapIssue.gif](https://archive.blender.org/developer/F10191618/MouseWrapIssue.gif) *Note how the cube jumps in scale when the cursor wraps around the edge. That's not a bug in the gif; that's what actually happening.* I have encountered this issue on multiple computers with multiple mice. I first encountered it in Blender 2.91, but it is possible it has existed longer than that. **Exact steps for others to reproduce the error** Based on the default startup. 1. Select the default cube 2. Hit `s` for scale 3. Drag mouse past screen border so it wraps around. Drag it back and forth a couple times and the size should jump.

Andrew commented

2021-06-24 01:27:08 +02:00

Added subscriber: @Antyos

blender-admin commented

2021-06-24 01:27:08 +02:00

#102787 was marked as duplicate of this issue

blender-admin commented

2021-06-24 01:27:08 +02:00

#75528 was marked as duplicate of this issue

blender-admin commented

2021-06-24 01:27:08 +02:00

#100438 was marked as duplicate of this issue

Nicholas Rishel commented

2021-06-24 04:41:38 +02:00

Added subscriber: @PrototypeNM1

Nicholas Rishel commented

2021-06-24 04:41:38 +02:00

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

Nicholas Rishel commented

2021-06-24 04:41:38 +02:00

Triaging notes: the source of this bug is that cursor wrap move the cursor, but when it later checks the mouse position it hasn't yet been updated, so it re-wraps. This behavior has always been preset but is variably likely to occur. I don't at this time have a hypothesis as to why the cursor position is sometimes not updated before the next mouse move message is processed (we use the current mouse position, not the position at the time of the Win32 event).

Ghost on Mac solves this by having a timeout before the cursor can wrap again (there is or was an open issue where the timeout presumably wasn't sufficient for ARM Mac).

Triaging notes: the source of this bug is that cursor wrap move the cursor, but when it later checks the mouse position it hasn't yet been updated, so it re-wraps. This behavior has always been preset but is variably likely to occur. I don't at this time have a hypothesis as to why the cursor position is sometimes not updated before the next mouse move message is processed (we use the current mouse position, not the position at the time of the Win32 event). Ghost on Mac solves this by having a timeout before the cursor can wrap again (there is or was an open issue where the timeout presumably wasn't sufficient for ARM Mac).

Germano Cavalcante commented

2022-08-16 19:49:12 +02:00

Added subscribers: @yaR, @mano-wii

blender-admin commented

2022-08-18 14:32:49 +02:00

This issue was referenced by 29bc410c8a

This issue was referenced by 29bc410c8a67fcdc65827e30741eec1c8463df06

blender-admin commented

2022-08-18 14:32:49 +02:00

This issue was referenced by e4f1d71908

This issue was referenced by e4f1d719080ab15f4a33034a1eccacace4600b04

Germano Cavalcante commented

2022-08-19 15:11:02 +02:00

Added subscribers: @Floatharr, @Burhursta, @Symilate, @jkinzel, @cheteron, @joachip, @lictex_1, @PratikPB2123, @lichtwerk, @LazyDodo, @Zcyber, @CookItOff, @AgentSam-2, @Aumnescio, @Pathogen

Germano Cavalcante commented

2022-08-19 15:12:00 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Germano Cavalcante closed this issue

2022-08-19 15:12:00 +02:00

Germano Cavalcante self-assigned this 2022-08-19 15:12:00 +02:00

Joachim Michaelis commented

2022-11-06 13:40:35 +01:00

The mouse pointer is still jumping around sporadically as mentioned in https://developer.blender.org/T75528
I'm not entirely sure it has to do with the pointer reaching the edge of the screen or not.

The mouse pointer is still jumping around sporadically as mentioned in https://developer.blender.org/T75528 I'm not entirely sure it has to do with the pointer reaching the edge of the screen or not.

CHET commented

2022-11-07 01:17:42 +01:00

Same problem yet

In #89399#1441412, @joachip wrote:
The mouse pointer is still jumping around sporadically as mentioned in https://developer.blender.org/T75528
I'm not entirely sure it has to do with the pointer reaching the edge of the screen or not.

Same problem yet > In #89399#1441412, @joachip wrote: > The mouse pointer is still jumping around sporadically as mentioned in https://developer.blender.org/T75528 > I'm not entirely sure it has to do with the pointer reaching the edge of the screen or not.

Timothy Cook commented

2022-11-07 05:51:52 +01:00

Removed subscriber: @CookItOff

Germano Cavalcante commented

2022-11-07 13:18:59 +01:00

One note to keep in mind is that this issue has only been resolved on Windows.
Each platform has a different solution.

One note to keep in mind is that this issue has only been resolved on Windows. Each platform has a different solution.

CHET commented

2022-11-07 15:16:22 +01:00

Not resolved on Windows. I have Windows 10, problem still exists

In #89399#1441920, @mano-wii wrote:
One note to keep in mind is that this issue has only been resolved on Windows.
Each platform has a different solution.

Not resolved on Windows. I have Windows 10, problem still exists > In #89399#1441920, @mano-wii wrote: > One note to keep in mind is that this issue has only been resolved on Windows. > Each platform has a different solution.

Joachim Michaelis commented

2022-11-10 13:00:15 +01:00

I forgot to mention that I was indeed using Windows 10 pro 64 bit. I have recreated this on several different Windows machines. I even went to a coworker's desk and asked him if he had Blender installed (which he did), and then immediately recreated the problem there. This rules out my personal configuration of Windows. Enabling/disabling mouse acceleration has no effect. I have not tried changing the USB polling rate, because I don't think I even have that setting available. I'm not using any special kind of mouse driver, just whatever is default in Windows. I've had the problem since the very first version of Blender I tried (probably 2.79 or so), and It's still there in Blender 3.3.0.

It's very easy to recreate, as it happens all the time you drag any object or value input field. Basically any mouse drag operation of the kind where the mouse pointer becomes hidden. In fact, it only happens in the situations where the pointer becomes hidden, so maybe that's a hint to where the problem comes from? Considering how often this happens, I think fixing this issue should be high priority.

I forgot to mention that I was indeed using Windows 10 pro 64 bit. I have recreated this on several different Windows machines. I even went to a coworker's desk and asked him if he had Blender installed (which he did), and then immediately recreated the problem there. This rules out my personal configuration of Windows. Enabling/disabling mouse acceleration has no effect. I have not tried changing the USB polling rate, because I don't think I even have that setting available. I'm not using any special kind of mouse driver, just whatever is default in Windows. I've had the problem since the very first version of Blender I tried (probably 2.79 or so), and It's still there in Blender 3.3.0. It's very easy to recreate, as it happens all the time you drag any object or value input field. Basically *any* mouse drag operation of the kind where the mouse pointer becomes hidden. In fact, it only happens in the situations where the pointer becomes hidden, so maybe that's a hint to where the problem comes from? Considering how often this happens, I think fixing this issue should be high priority.

Germano Cavalcante commented

2022-11-10 13:44:53 +01:00

The fix was not applied in 3.3. But I just added it to the list of fixes to be backported.
#100749 (Blender LTS: Maintenance Task 3.3)

The fix was not applied in 3.3. But I just added it to the list of fixes to be backported. #100749 (Blender LTS: Maintenance Task 3.3)

Richard Antalik commented

2022-11-27 20:40:26 +01:00

Added subscriber: @Cdmium

Henrique Corrêa commented

2022-12-07 22:55:43 +01:00

Added subscriber: @HeCorr

Henrique Corrêa commented

2022-12-07 22:55:43 +01:00

This seems to have created a regression with drawing tablets, making the behavior even more extreme than what this Task originally addressed.

It worked fine in 3.3.1 (b292cfe5a9) but in 3.3.2 (bf24652e38) something seems to go wrong and the action breaks when the cursor returns to the 3D View.
Interestingly, it only seems to break when moving the cursor slowly, though it's rather inconsistent. Sometimes it happens, sometimes it doesn't (I tested it on 3.3.1 using similar movements and it didn't break).

This is a really big deal for me since I exclusively animate with a drawing tablet and I'm sure many others also do.

If necessary I can create a separate Task. Just let me know.

Here's some more info:

OS: Windows 10 Pro (1909)
GPU: Asus RTX 3060 (12GB)
Tablet: Wacom Bamboo Pen CTL-470

Here's a video demonstrating it:
2022-12-07 18-34-02.mp4

This seems to have created a regression with drawing tablets, making the behavior even more extreme than what this Task originally addressed. It worked fine in 3.3.1 (b292cfe5a936) but in 3.3.2 (bf24652e38a2) something seems to go wrong and the action breaks when the cursor returns to the 3D View. Interestingly, it only seems to break when moving the cursor slowly, though it's rather inconsistent. Sometimes it happens, sometimes it doesn't (I tested it on 3.3.1 using similar movements and it didn't break). This is a **really** big deal for me since I exclusively animate with a drawing tablet and I'm sure many others also do. If necessary I can create a separate Task. Just let me know. Here's some more info: - OS: Windows 10 Pro (1909) - GPU: Asus RTX 3060 (12GB) - Tablet: Wacom Bamboo Pen CTL-470 Here's a video demonstrating it: [2022-12-07 18-34-02.mp4](https://archive.blender.org/developer/F14024941/2022-12-07_18-34-02.mp4)

Samuel Sebastian Tekrenius commented

2022-12-08 04:32:54 +01:00

In #89399#1456365, @HeCorr wrote:
This seems to have created a regression with drawing tablets...
..snip..

Here's a video demonstrating it:
.. snip..

Just for the sake of completeness, it might also be worth mentioning the following:

Operating system
Model of GPU
Model of the drawing tablet

Generally speaking, this issue does occur on a wide range of systems and devices, but sometimes it helps to know more about the affected systems/devices.

Sidenote: It's insane how long this problem has been around, and still no solution in sight.

> In #89399#1456365, @HeCorr wrote: > This seems to have created a regression with drawing tablets... > ..snip.. > > Here's a video demonstrating it: > .. snip.. Just for the sake of completeness, it might also be worth mentioning the following: - Operating system - Model of GPU - Model of the drawing tablet Generally speaking, this issue does occur on a wide range of systems and devices, but sometimes it helps to know more about the affected systems/devices. Sidenote: It's insane how long this problem has been around, and still no solution in sight.

Henrique Corrêa commented

2022-12-08 17:10:52 +01:00

In #89399#1456476, @AgentSam-2 wrote:
Just for the sake of completeness, it might also be worth mentioning the following

Thanks for the suggestion, I've edited my post.

Sidenote: It's insane how long this problem has been around, and still no solution in sight.

True. Technically it did get fixed, but broke tablet use in the process.

> In #89399#1456476, @AgentSam-2 wrote: > Just for the sake of completeness, it might also be worth mentioning the following Thanks for the suggestion, I've edited my post. > Sidenote: It's insane how long this problem has been around, and still no solution in sight. True. Technically it did get fixed, but broke tablet use in the process.

Germano Cavalcante commented

2022-12-14 20:10:23 +01:00

Committed a different solution. Hope now solves for all different cases in Windows: a3a9459050

Committed a different solution. Hope now solves for all different cases in Windows: a3a9459050

Joachim Michaelis commented

2022-12-27 12:20:37 +01:00

Confirmed fixed in Blender 3.4.0 and 3.4.1 (Windows versions)! Thank you!

Confirmed **fixed** in Blender 3.4.0 and 3.4.1 (Windows versions)! Thank you!

Floatharr commented

2022-12-27 13:38:55 +01:00

In #89399#1466124, @joachip wrote:
Confirmed fixed in Blender 3.4.0 and 3.4.1 (Windows versions)! Thank you!

Not fixed, check your mouse polling rate. It's significantly harder to reproduce at the default setting of 125hz and when the mouse is moving slowly. This is me testing 2.93.6 LTS, 3.4.1 Stable, and 3.5.0 Alpha (downloaded 5 minutes ago) at 125hz, and 1000hz on Windows 10. At best I feel like the problem is improved on the new versions when the mouse is moving slowly. Personally I'm still keeping continuous grab off. 5iGidXavay.mp4

> In #89399#1466124, @joachip wrote: > Confirmed **fixed** in Blender 3.4.0 and 3.4.1 (Windows versions)! Thank you! Not fixed, check your mouse polling rate. It's significantly harder to reproduce at the default setting of 125hz and when the mouse is moving slowly. This is me testing 2.93.6 LTS, 3.4.1 Stable, and 3.5.0 Alpha (downloaded 5 minutes ago) at 125hz, and 1000hz on Windows 10. At best I feel like the problem is improved on the new versions when the mouse is moving slowly. Personally I'm still keeping continuous grab off. [5iGidXavay.mp4](https://archive.blender.org/developer/F14095109/5iGidXavay.mp4)

Christoph Lendenfeld referenced this issue

2023-02-10 11:56:22 +01:00

Blender LTS: Maintenance Task 3.3 #100749

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Mouse wrapping causes erratic movement #89399