Snap performance regression at high poll rate #93408

New Issue

melak47 · 2021-11-26T16:06:40+01:00

melak47 commented

2021-11-26 16:06:40 +01:00

System Information
Operating system: Windows-10-10.0.22000-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.76

Blender Version
Broken: version: 3.0.0 Release Candidate, branch: master, commit date: 2021-11-25 17:24, hash: 2fb8c6805a (still broken in 3.1 7b5a6f452a).
Worked: 2.93.4 release

Short description of error
When using a mouse with a high poll rate, blender 3.0 can't seem to keep up with
mouse movements when snapping is on.
Even just 250Hz instead of 125Hz grinds the snapping to a halt in a trivial scene,
making it almost unusable unless you move the mouse veryslowly.

Exact steps for others to reproduce the error
Example scene created in blender with factory defaults, with two cubes and snapping
set to "face" and "center":
repro.blend

Using a mouse with a polling rate higher than 125Hz (many gaming mice go up to 1000Hz):

Select the smaller cube,
press g,
hold ctrl for snapping,
drag the smaller cube over the large cube.
Observe the snapped location updating less and less often the faster you drag:
pTazSmLAXx.mp4

Compare with blender 2.93 which doesn't seem to have a problem even at 1000Hz:
GskIXNAhU4.mp4

Workarounds

don't use a gaming mouse ( the extra buttons are nice for blender, though :| )
change the polling rate in the mouse's accompanying software if possible

**System Information** Operating system: Windows-10-10.0.22000-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3090/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 496.76 **Blender Version** Broken: version: 3.0.0 Release Candidate, branch: master, commit date: 2021-11-25 17:24, hash: `2fb8c6805a` (still broken in 3.1 7b5a6f452aa5). Worked: 2.93.4 release **Short description of error** When using a mouse with a high poll rate, blender 3.0 can't seem to keep up with mouse movements when snapping is on. Even just 250Hz instead of 125Hz grinds the snapping to a halt in a trivial scene, making it almost unusable unless you move the mouse *very*slowly. **Exact steps for others to reproduce the error** Example scene created in blender with factory defaults, with two cubes and snapping set to "face" and "center": [repro.blend](https://archive.blender.org/developer/F12289627/repro.blend) Using a mouse with a polling rate higher than 125Hz (many gaming mice go up to 1000Hz): 1. Select the smaller cube, 2. press g, 3. hold ctrl for snapping, 4. drag the smaller cube over the large cube. Observe the snapped location updating less and less often the faster you drag: [pTazSmLAXx.mp4](https://archive.blender.org/developer/F12289266/pTazSmLAXx.mp4) Compare with blender 2.93 which doesn't seem to have a problem even at 1000Hz: [GskIXNAhU4.mp4](https://archive.blender.org/developer/F12290122/GskIXNAhU4.mp4) **Workarounds** - don't use a gaming mouse ( the extra buttons are nice for blender, though :| ) - change the polling rate in the mouse's accompanying software if possible

melak47 commented

2021-11-26 16:06:40 +01:00

Added subscriber: @melak47

Vladimir commented

2021-11-29 12:18:23 +01:00

Added subscriber: @Wovchick

Germano Cavalcante commented

2021-12-06 14:14:24 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2021-12-06 14:14:24 +01:00

As far as I know, the snapping part of the transform code hasn't gone through changes that would justify this lag. This must be a collateral effect of changes in another area.

Does the problem only appear when you press Ctrl? What happens if snapping is already enabled in the scene? And what happens if you change the shortcut to a key other than Ctrl?

As far as I know, the snapping part of the transform code hasn't gone through changes that would justify this lag. This must be a collateral effect of changes in another area. Does the problem only appear when you press Ctrl? What happens if snapping is already enabled in the scene? And what happens if you change the shortcut to a key other than Ctrl?

melak47 commented

2021-12-06 15:00:56 +01:00

In #93408#1266235, @mano-wii wrote:
As far as I know, the snapping part of the transform code hasn't gone through changes that would justify this lag. This must be a collateral effect of changes in another area.

Does the problem only appear when you press Ctrl? What happens if snapping is already enabled in the scene?

If I enable snapping in the menu header, it behaves the same without holding control.
Using the transform gizmo tool with snapping on instead of pressing g, too.

And what happens if you change the shortcut to a key other than Ctrl?

> In #93408#1266235, @mano-wii wrote: > As far as I know, the snapping part of the transform code hasn't gone through changes that would justify this lag. This must be a collateral effect of changes in another area. > > Does the problem only appear when you press Ctrl? What happens if snapping is already enabled in the scene? If I enable snapping in the menu header, it behaves the same without holding control. Using the transform gizmo tool with snapping on instead of pressing `g`, too. > And what happens if you change the shortcut to a key other than Ctrl?

Germano Cavalcante commented

2021-12-22 20:06:53 +01:00

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

Germano Cavalcante self-assigned this 2021-12-22 20:06:53 +01:00

Germano Cavalcante commented

2021-12-22 20:06:53 +01:00

I can confirm on a mouse with a polling rate of 500Hz
fba9cd019f is the first bad commit

I can confirm on a mouse with a polling rate of 500Hz fba9cd019f is the first bad commit

blender-admin commented

2021-12-22 20:11:05 +01:00

This issue was referenced by b2e15cb19d

This issue was referenced by b2e15cb19daba51d82191e446b705d11a0ec96fd