Regression: very long input delay when dragging some gizmos handles in macOS #96435

New Issue

William Reynish · 2022-03-14T13:34:46+01:00

William Reynish commented

2022-03-14 13:34:46 +01:00

System Information

Operating system:	macOS-12.1-x86_64-i386-64bit 64 Bits	@WilliamReynish
	macOS-12.3-x86_64-i386-64bit 64 Bits	@p1x3l
	macOS 12.2.1	@veily

Graphics card:	AMD Radeon Pro 5500M OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.7.101	@WilliamReynish
	AMD Radeon Pro 5500M OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.7.101	@p1x3l
	AMD Readon RX 6900 XT 16GB	@veily

In #96435#1346701, @Sergey wrote:
I can reproduce this issue on Mac Pro 2019 AMD W6800X, but NOT on MacBook with Intel Iris GPU.

Blender Version
Broken: 3.1.1 Release Candidate, branch: master, commit date: 2022-03-24 13:38, hash: fb2cb0324a
Worked: 3.1.0

Short description of error
When dragging some gizmo handles, the user has to drag the mouse cursor over a huge distance before the drag is registered as an input. That is even if the drag threshold is set to the minimum level. Used to work normally in 3.1 and earlier releases. This makes using the gizmos extremely slow and unresponsive.

blender1.mov	Screen Recording 2022-03-14 at 13.14.54.mov

Exact steps for others to reproduce the error

Switch to the Scale tool
Pull either of the colored axis handles
You have to pull them extremely far before it start to actually scale at all.

Some gizmo handles work better, such as the move gizmo handles. Not sure why there is such a difference.

See the below video recording. As you can see, drag threshold is set to the minimum amount here, and you can see the cursor traveling very far before it starts to scale

**System Information** |Operating system:|macOS-12.1-x86_64-i386-64bit 64 Bits|@WilliamReynish | -- | -- | -- | ||macOS-12.3-x86_64-i386-64bit 64 Bits|@p1x3l ||macOS 12.2.1|@veily |Graphics card:|AMD Radeon Pro 5500M OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.7.101|@WilliamReynish | -- | -- | -- | ||AMD Radeon Pro 5500M OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.7.101|@p1x3l ||AMD Readon RX 6900 XT 16GB|@veily > In #96435#1346701, @Sergey wrote: > I can reproduce this issue on Mac Pro 2019 AMD W6800X, but NOT on MacBook with Intel Iris GPU. **Blender Version** Broken: 3.1.1 Release Candidate, branch: master, commit date: 2022-03-24 13:38, hash: `fb2cb0324a` Worked: 3.1.0 **Short description of error** When dragging some gizmo handles, the user has to drag the mouse cursor over a huge distance before the drag is registered as an input. That is even if the drag threshold is set to the minimum level. Used to work normally in 3.1 and earlier releases. This makes using the gizmos extremely slow and unresponsive. |[blender1.mov](https://archive.blender.org/developer/F12950141/blender1.mov)|[Screen Recording 2022-03-14 at 13.14.54.mov](https://archive.blender.org/developer/F12926689/Screen_Recording_2022-03-14_at_13.14.54.mov) | -- | -- | **Exact steps for others to reproduce the error** - Switch to the Scale tool - Pull either of the colored axis handles - You have to pull them extremely far before it start to actually scale at all. Some gizmo handles work better, such as the move gizmo handles. Not sure why there is such a difference. See the below video recording. As you can see, drag threshold is set to the minimum amount here, and you can see the cursor traveling very far before it starts to scale

William Reynish commented

2022-03-14 13:34:46 +01:00

Added subscriber: @WilliamReynish

blender-admin commented

2022-03-14 13:34:46 +01:00

#96789 was marked as duplicate of this issue

blender-admin commented

2022-03-14 13:34:46 +01:00

#96811 was marked as duplicate of this issue

Henrik D. commented

2022-03-14 16:34:39 +01:00

Added subscriber: @HDMaster84

Henrik D. commented

2022-03-14 16:34:39 +01:00

Cannot reproduce on linux.
Can you reproduce it with a factory settings?

System Information
Operating system: Linux-5.15.0-2-amd64-x86_64-with-glibc2.33 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.86

Blender Version
version: 3.2.0 Alpha, branch: master, commit date: 2022-03-14 15:13, hash: cff6eb6580

Cannot reproduce on linux. Can you reproduce it with a factory settings? **System Information** Operating system: Linux-5.15.0-2-amd64-x86_64-with-glibc2.33 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.86 **Blender Version** version: 3.2.0 Alpha, branch: master, commit date: 2022-03-14 15:13, hash: `cff6eb6580`

William Reynish commented

2022-03-14 19:25:55 +01:00

Yes. Should have mentioned. Factory settings.

Pratik Borhade commented

2022-03-17 14:18:22 +01:00

Added subscribers: @mano-wii, @PratikPB2123

Pratik Borhade commented

2022-03-17 14:18:22 +01:00

Hi @WilliamReynish , can't reproduce either. Probably Mac specific this issue is? @mano-wii , can you confirm?
Maybe got affected by 1f1dcf41d5

Operating system : Windows-10-10.0.18362-SP0 64 Bits
Graphics card : AMD Radeon(TM) 535 ATI Technologies .```

Hi @WilliamReynish , can't reproduce either. Probably Mac specific this issue is? @mano-wii , can you confirm? Maybe got affected by 1f1dcf41d5 ```System Information Operating system : Windows-10-10.0.18362-SP0 64 Bits Graphics card : AMD Radeon(TM) 535 ATI Technologies .```

Germano Cavalcante commented

2022-03-17 20:44:02 +01:00

Added subscriber: @ideasman42

Germano Cavalcante commented

2022-03-17 20:44:02 +01:00

I can't replicate on mac.
But I feel that the report also needs to inform:

DPI of the monitor or tablet used
Mouse or pen

@ideasman42, is this something for you to take a look at?

System Information
Operating system: macOS-12.2-arm64-arm-64bit 64 Bits
Graphics card: Apple M1 Apple 4.1 Metal - 76.3

I can't replicate on mac. But I feel that the report also needs to inform: - DPI of the monitor or tablet used - Mouse or pen @ideasman42, is this something for you to take a look at? --- **System Information** Operating system: `macOS-12.2-arm64-arm-64bit 64 Bits` Graphics card: `Apple M1 Apple 4.1 Metal - 76.3`

Philipp Oeser commented

2022-03-21 11:55:34 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-03-21 11:55:34 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Philipp Oeser commented

2022-03-21 11:55:34 +01:00

Also cannot reproduce here.

In #96435#1324890, @mano-wii wrote:
I can't replicate on mac.
But I feel that the report also needs to inform:

DPI of the monitor or tablet used

Mouse or pen

@WilliamReynish : can you fill the information gap?

Also cannot reproduce here. > In #96435#1324890, @mano-wii wrote: > I can't replicate on mac. > But I feel that the report also needs to inform: > - DPI of the monitor or tablet used > - Mouse or pen @WilliamReynish : can you fill the information gap?

Pratik Borhade commented

2022-03-28 05:39:29 +02:00

Now we also have #96811, #96789 (both reported on Mac OS)

Broken: version: 3.2.0 Alpha

Hard to tell if 3.2 is the first version where gizmo dragging is affected. Other reports are claiming exact same issue on previous release versions.

Now we also have #96811, #96789 (both reported on Mac OS) > Broken: version: 3.2.0 Alpha Hard to tell if 3.2 is the first version where gizmo dragging is affected. Other reports are claiming exact same issue on previous release versions.

Germano Cavalcante commented

2022-03-30 21:39:57 +02:00

Added subscribers: @veily, @p1x3l

Veily commented

2022-03-30 22:08:59 +02:00

Having the same issue with apple magic trackpad or a logitech mouse. However DPI is more interesting, I just tried to turn down the resolution of one of my external monitor to low resolution mode and it's a lot less noticible (to a degree that I feel like I can live with it if it's not fixed at all). Looks like it definitely has something to do with DPI. I can simply drag the blender window between low and high DPI monitors and the delay is different when the window is on the high DPI monitor than when it's on low DPI monitor.

Germano Cavalcante commented

2022-03-31 15:05:22 +02:00

To know what's going on, I think we should check what happens inside WM_event_drag_test_with_delta.
Is this function not being called when it should? Is the value of drag_threshold or drag_delta being calculated wrong?

I tested it on screens with different DPIs but I still couldn't replicate the problem :\

To know what's going on, I think we should check what happens inside `WM_event_drag_test_with_delta`. Is this function not being called when it should? Is the value of `drag_threshold` or `drag_delta` being calculated wrong? I tested it on screens with different DPIs but I still couldn't replicate the problem :\

Campbell Barton commented

2022-04-01 08:27:51 +02:00

I also can't redo the error, tried with UI scale set to 2.0 & 4.0.

Since this is reported to be working in 3.1.0 and not in 3.1.1 there aren't so many commits that could have caused this. Checking over the commits I don't see any likely candidates.

It's unfortunate this got into the 3.1 release, it would help a lot if someone on macOS could bisect the error to find when this broke.

@PratikPB2123 most of the changes to dragging were not included in 3.1x (1f1dcf41d5 will only be in 3.2x for e.g.).

It's also strange this only impacts macOS as most of the code in this area is the same for all platforms.

Edit: other reports listed as duplicates of this say that 3.0.1 was the last working version, could someone confirm this definitely worked in 3.1.0?

I also can't redo the error, tried with UI scale set to 2.0 & 4.0. Since this is reported to be working in 3.1.0 and not in 3.1.1 there aren't so many commits that could have caused this. Checking over the commits I don't see any likely candidates. It's unfortunate this got into the 3.1 release, it would help a lot if someone on macOS could bisect the error to find when this broke. @PratikPB2123 most of the changes to dragging were not included in 3.1x (1f1dcf41d5 will only be in 3.2x for e.g.). It's also strange this only impacts macOS as most of the code in this area is the same for all platforms. ---- Edit: other reports listed as duplicates of this say that 3.0.1 was the last working version, could someone confirm this definitely worked in 3.1.0?

Campbell Barton changed title from ~~Very long input delay when dragging some gizmos handles~~ to Regression: very long input delay when dragging some gizmos handles in macOS

2022-04-01 08:30:44 +02:00

Veily commented

2022-04-02 01:25:50 +02:00

Are you reproducing with a high DPI monitor? To clarify, for me changing UI scale inside the blender does not affect it, only OS level scaling does. My guess is that it's related to how macOS handles UI scaling in high DPI monitor.

Are you reproducing with a high DPI monitor? To clarify, for me changing UI scale inside the blender does not affect it, only OS level scaling does. My guess is that it's related to how macOS handles UI scaling in high DPI monitor. ![Screen Shot 2022-04-01 at 4.21.20 PM.png](https://archive.blender.org/developer/F12962844/Screen_Shot_2022-04-01_at_4.21.20_PM.png)

ChenYZ commented

2022-04-13 11:06:05 +02:00

Added subscriber: @didi404

ChenYZ commented

2022-04-13 11:06:05 +02:00

This comment was removed by @didi404

*This comment was removed by @didi404*

ChenYZ commented

2022-04-13 11:07:28 +02:00

I am a macOS user and have encountered this problem in use.
There is a noticeable delay when dragging Gizmo to move, scale, or rotate, especially when along a particular axial and axial plane.

I am a macOS user and have encountered this problem in use. There is a noticeable delay when dragging Gizmo to move, scale, or rotate, especially when along a particular axial and axial plane.

Sergey Sharybin commented

2022-04-26 10:28:12 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2022-04-26 10:28:12 +02:00

I can reproduce this issue on Mac Pro 2019 AMD W6800X, but NOT on MacBook with Intel Iris GPU.

Issues I observe on the Mac Pro:

The Gizmo axis highlight takes a while on mouse-hover (one would expect mouse-over o nan axis to immediately highlight it, here it takes a second or two).
There is the same lag on update as described in the report
Sometimes there is also a lag when you release mouse after transform
Keeping mouse cursor under the gizmo and using magic mouse to rotate viewport is a straight way to cause bigger Blender freeze, including the spinning ball. After 10sec or so Blender unfreezes, so it's not a "permafrost" :)

I can reproduce this issue on Mac Pro 2019 AMD W6800X, but NOT on MacBook with Intel Iris GPU. Issues I observe on the Mac Pro: - The Gizmo axis highlight takes a while on mouse-hover (one would expect mouse-over o nan axis to immediately highlight it, here it takes a second or two). - There is the same lag on update as described in the report - Sometimes there is also a lag when you release mouse after transform - Keeping mouse cursor under the gizmo and using magic mouse to rotate viewport is a straight way to cause bigger Blender freeze, including the spinning ball. After 10sec or so Blender unfreezes, so it's not a "permafrost" :)

Guido commented

2022-04-26 10:45:29 +02:00

Added subscriber: @Nurb2Kea

Guido commented

2022-04-26 10:45:29 +02:00

I can confirm this also for blender 3.2
version: 3.2.0 Alpha, branch: master, commit date: 2022-04-24 12:33, hash: 17eb8a9ceb

(macos 12.3.1 + latest brew updates + xcode 13.2) + magic mouse

I can confirm this also for blender 3.2 version: 3.2.0 Alpha, branch: master, commit date: 2022-04-24 12:33, hash: 17eb8a9ceb (macos 12.3.1 + latest brew updates + xcode 13.2) + magic mouse ![system specs.jpg](https://archive.blender.org/developer/F13029612/system_specs.jpg)

Philipp Oeser commented

2022-05-09 13:35:01 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Philipp Oeser commented

2022-05-09 13:35:01 +02:00

In #96435#1346701, @Sergey wrote:
I can reproduce this issue on Mac Pro 2019 AMD W6800X, but NOT on MacBook with Intel Iris GPU.

Issues I observe on the Mac Pro:

The Gizmo axis highlight takes a while on mouse-hover (one would expect mouse-over o nan axis to immediately highlight it, here it takes a second or two).

There is the same lag on update as described in the report

Sometimes there is also a lag when you release mouse after transform

Keeping mouse cursor under the gizmo and using magic mouse to rotate viewport is a straight way to cause bigger Blender freeze, including the spinning ball. After 10sec or so Blender unfreezes, so it's not a "permafrost" :)

Will consider this confirmed.
Since I dont have the hardware it would be super nice if someone could bisect this.

> In #96435#1346701, @Sergey wrote: > I can reproduce this issue on Mac Pro 2019 AMD W6800X, but NOT on MacBook with Intel Iris GPU. > > Issues I observe on the Mac Pro: > - The Gizmo axis highlight takes a while on mouse-hover (one would expect mouse-over o nan axis to immediately highlight it, here it takes a second or two). > - There is the same lag on update as described in the report > - Sometimes there is also a lag when you release mouse after transform > - Keeping mouse cursor under the gizmo and using magic mouse to rotate viewport is a straight way to cause bigger Blender freeze, including the spinning ball. After 10sec or so Blender unfreezes, so it's not a "permafrost" :) Will consider this confirmed. Since I dont have the hardware it would be super nice if someone could bisect this.

Julian Eisel commented

2022-05-09 17:30:19 +02:00

Added subscriber: @JulianEisel

Julian Eisel commented

2022-05-09 17:30:19 +02:00

So is this issue only happening when multiple monitors are involved? There seem people suggesting that, and it's not uncommon to have DPI issues on setups with multiple monitors and different DPIs. OTOH some comments (esp. Sergey's) sound more like a GPU driver issue. Only people with AMD cards seem to have the issue.

I cannot reproduce a strong lag like shown in the video. However, with the combined transform manipulators I do get a bit of a lag:

macOS	Linux
Screen Recording 2022-05-09 at 5.35.35 PM.mov	gizmo_highlight-2022-05-09_17.32.53.mp4
On my Linux machine it's notably more responsive.

System Information
Operating system: macOS-12.3.1-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 5700 XT OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.8.15

All things considered this does seem more like a GPU driver issue.

So is this issue only happening when multiple monitors are involved? There seem people suggesting that, and it's not uncommon to have DPI issues on setups with multiple monitors and different DPIs. OTOH some comments (esp. Sergey's) sound more like a GPU driver issue. Only people with AMD cards seem to have the issue. I cannot reproduce a strong lag like shown in the video. However, with the combined transform manipulators I do get a bit of a lag: | macOS | Linux | | --- | --- | | [Screen Recording 2022-05-09 at 5.35.35 PM.mov](https://archive.blender.org/developer/F13061218/Screen_Recording_2022-05-09_at_5.35.35_PM.mov) | [gizmo_highlight-2022-05-09_17.32.53.mp4](https://archive.blender.org/developer/F13061210/gizmo_highlight-2022-05-09_17.32.53.mp4) | On my Linux machine it's notably more responsive. **System Information** Operating system: macOS-12.3.1-x86_64-i386-64bit 64 Bits Graphics card: AMD Radeon Pro 5700 XT OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.8.15 ---- All things considered this does seem more like a GPU driver issue.

Julian Eisel commented

2022-05-10 12:51:52 +02:00

Okay, Sergey noticed there's also quite a big lag when trying to rotate the view quickly while hovering specific gizmos. I can confirm that, even though for me it's only happening with the combined transform manipulator. So same symptom under slightly different conditions.

System Information
Operating system: macOS-12.3.1-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 5700 XT OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.8.15

At this point I think it's safe to consider this a GPU driver issue. Marking as responsibility of the #eevee_viewport module.

Okay, Sergey noticed there's also quite a big lag when trying to rotate the view quickly while hovering specific gizmos. I can confirm that, even though for me it's only happening with the combined transform manipulator. So same symptom under slightly different conditions. **System Information** Operating system: macOS-12.3.1-x86_64-i386-64bit 64 Bits Graphics card: AMD Radeon Pro 5700 XT OpenGL Engine ATI Technologies Inc. 4.1 ATI-4.8.15 ---- At this point I think it's safe to consider this a GPU driver issue. Marking as responsibility of the #eevee_viewport module.

Sergey Sharybin commented

2022-05-10 14:49:29 +02:00

@JulianEisel, the dual-monitor might be a factor here, but in my case it happens on a single monitor setup. Although, it is a high-res display.

Bisected the issue I am having here to 0cb5eae9d0.

@JulianEisel, the dual-monitor might be a factor here, but in my case it happens on a single monitor setup. Although, it is a high-res display. Bisected the issue I am having here to 0cb5eae9d0.

Campbell Barton commented

2022-05-11 13:03:56 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Campbell Barton closed this issue

2022-05-11 13:03:56 +02:00

Campbell Barton self-assigned this 2022-05-11 13:03:56 +02:00

Campbell Barton commented

2022-05-11 13:03:56 +02:00

Committed 5045968f24 as this caused problems for both macOS and Windows+NVidia.

Committed 5045968f24 as this caused problems for both macOS and Windows+NVidia.

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

Regression: very long input delay when dragging some gizmos handles in macOS #96435