Continuous grab is broken 2.92.0 Alpha macOS #82870

New Issue

Yevgeny Makarov · 2020-11-20T15:26:14+01:00

Yevgeny Makarov commented

2020-11-20 15:26:14 +01:00

System Information
Operating system: Darwin-19.6.0-x86_64-i386-64bit 64 Bits
Graphics card: AMD Radeon Pro 455 OpenGL Engine ATI Technologies Inc. 4.1 ATI-3.10.18

Blender Version
Broken: version: 2.92.0 Alpha, Fri, Nov 20, 14:41, 96995b2343.
Worked: ~

Short description of error
When the cursor crosses the editor border, the value jumps/doubles.
It doesn't matter if it's a tablet, mouse, or trackpad.

This problem is also present in previous versions (at least in 2.83 it definitely is)
but after 96200110eb it began to happen all the time.

Actually there is a report for Windows #59836, but it's set to just todo.

continuous-grab-issue.mov

Here's what I see, this is a normal case:

GHOST x_mouse 558
GHOST x_accum 0 
GHOST warped_x_mouse 558 
WM    event.x 1116

GHOST x_mouse 559
GHOST x_accum 0 
GHOST warped_x_mouse 1 
WM    event.x 1118

GHOST x_mouse 1
GHOST x_accum 558 
GHOST warped_x_mouse 1 
WM    event.x 1118

And this is the wrong one:

GHOST x_mouse 558
GHOST x_accum 0 
GHOST warped_x_mouse 558 

WM    event.x 1116

GHOST x_mouse 559
GHOST x_accum 0 
GHOST warped_x_mouse 1 

GHOST x_mouse 559
GHOST x_accum 558 <--- !!!
GHOST warped_x_mouse 1 

WM    event.x 1118
WM    event.x 2234

CC @brecht

**System Information** Operating system: Darwin-19.6.0-x86_64-i386-64bit 64 Bits Graphics card: AMD Radeon Pro 455 OpenGL Engine ATI Technologies Inc. 4.1 ATI-3.10.18 **Blender Version** Broken: version: 2.92.0 Alpha, Fri, Nov 20, 14:41, `96995b2343`. Worked: ~ **Short description of error** When the cursor crosses the editor border, the value jumps/doubles. It doesn't matter if it's a tablet, mouse, or trackpad. This problem is also present in previous versions (at least in 2.83 it definitely is) but after 96200110eb it began to happen all the time. Actually there is a report for Windows #59836, but it's set to just todo. [continuous-grab-issue.mov](https://archive.blender.org/developer/F9337447/continuous-grab-issue.mov) Here's what I see, this is a normal case: ``` GHOST x_mouse 558 GHOST x_accum 0 GHOST warped_x_mouse 558 WM event.x 1116 GHOST x_mouse 559 GHOST x_accum 0 GHOST warped_x_mouse 1 WM event.x 1118 GHOST x_mouse 1 GHOST x_accum 558 GHOST warped_x_mouse 1 WM event.x 1118 ``` And this is the wrong one: ``` GHOST x_mouse 558 GHOST x_accum 0 GHOST warped_x_mouse 558 WM event.x 1116 GHOST x_mouse 559 GHOST x_accum 0 GHOST warped_x_mouse 1 GHOST x_mouse 559 GHOST x_accum 558 <--- !!! GHOST warped_x_mouse 1 WM event.x 1118 WM event.x 2234 ``` CC @brecht

Yevgeny Makarov commented

2020-11-20 15:26:14 +01:00

Added subscribers: @brecht, @jenkm

Yevgeny Makarov commented

2020-11-20 15:37:58 +01:00

I mean, it seems that the value accumulates but the cursor position is not updated,
and at the next event, the previous cursor position is used and the position is again accumulated.

I mean, it seems that the value accumulates but the cursor position is not updated, and at the next event, the previous cursor position is used and the position is again accumulated.

Germano Cavalcante commented

2020-11-23 20:08:50 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-11-23 20:08:50 +01:00

It seems to be a high priority issue.
I can't reproduce the problem on windows, in fact it seems to be MacOS specific.

It seems to be a high priority issue. I can't reproduce the problem on windows, in fact it seems to be MacOS specific.

Brecht Van Lommel commented

2020-11-24 19:21:33 +01:00

Added subscriber: @PrototypeNM1

Brecht Van Lommel commented

2020-11-24 19:21:33 +01:00

I don't have time to look into this. @PrototypeNM1 or @jenkm worked on this and they would be the ones to look into a fix. If there is no quick fix, it's best to revert the patch until this issue is fixed.

Also @jenkm, as a developer you can triage the bug immediately and set appropriate tags, confirmation status and priority.

I don't have time to look into this. @PrototypeNM1 or @jenkm worked on this and they would be the ones to look into a fix. If there is no quick fix, it's best to revert the patch until this issue is fixed. Also @jenkm, as a developer you can triage the bug immediately and set appropriate tags, confirmation status and priority.

Nicholas Rishel commented

2020-11-25 04:20:23 +01:00

The equivalent Windows Ghost code tells the OS to update the mouse cursor position, then skips issuing a Ghost event as the OS will issue a new cursor move event with corrected position.

I think what's happening is that after wrapping/accumulating there remains stale mouse events in the OS event queue that previously would have been overwritten before the next event is issued. The only reason this hasn't surfaced on Windows is because inbetween mouse events aren't handled, only tablets.

The equivalent Windows Ghost code tells the OS to update the mouse cursor position, then skips issuing a Ghost event as the OS will issue a new cursor move event with corrected position. I think what's happening is that after wrapping/accumulating there remains stale mouse events in the OS event queue that previously would have been overwritten before the next event is issued. The only reason this hasn't surfaced on Windows is because inbetween mouse events aren't handled, only tablets.

Yevgeny Makarov commented

2020-11-25 11:14:32 +01:00

@brecht It was much better with these, (note 2.91 also has a similar regression, but less noticeable).

--- a/intern/ghost/intern/GHOST_SystemCocoa.mm
+++ b/intern/ghost/intern/GHOST_SystemCocoa.mm
@@ -1590,7 +1590,7 @@ - (void)windowWillClose:(NSNotification *)notification
         }
         case GHOST_kGrabWrap:  // Wrap cursor at area/window boundaries
         {
-          NSPoint mousePos = [event locationInWindow];
+          NSPoint mousePos = [cocoawindow mouseLocationOutsideOfEventStream];
           GHOST_TInt32 x_mouse = mousePos.x;
           GHOST_TInt32 y_mouse = mousePos.y;
           GHOST_Rect bounds, windowBounds, correctedBounds;

9e85812acc

Also I think the navigation gizmos needs to use GHOST_kGrabHide not GHOST_kGrabWrap, this will completely fix the problem for them.

@brecht It was much better with these, (note 2.91 also has a similar regression, but less noticeable). ``` --- a/intern/ghost/intern/GHOST_SystemCocoa.mm +++ b/intern/ghost/intern/GHOST_SystemCocoa.mm @@ -1590,7 +1590,7 @@ - (void)windowWillClose:(NSNotification *)notification } case GHOST_kGrabWrap: // Wrap cursor at area/window boundaries { - NSPoint mousePos = [event locationInWindow]; + NSPoint mousePos = [cocoawindow mouseLocationOutsideOfEventStream]; GHOST_TInt32 x_mouse = mousePos.x; GHOST_TInt32 y_mouse = mousePos.y; GHOST_Rect bounds, windowBounds, correctedBounds; ``` 9e85812acc *** Also I think the navigation gizmos needs to use GHOST_kGrabHide not GHOST_kGrabWrap, this will completely fix the problem for them.

Yevgeny Makarov commented

2020-11-26 20:52:17 +01:00

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

Yevgeny Makarov commented

2020-11-26 21:35:02 +01:00

OK, I found a third similar report #74918 and there was a fix for Linux d6fd03616e.
I will try to do the similar thing (use a time stamp and delay) for Mac.

And the fourth #75528.
And probably these, too #67362 #39144.

OK, I found a third similar report #74918 and there was a fix for Linux d6fd03616e. I will try to do the similar thing (use a time stamp and delay) for Mac. And the fourth #75528. And probably these, too #67362 #39144.

blender-admin commented

2020-11-29 17:35:33 +01:00

This issue was referenced by 9306e01b10

This issue was referenced by 9306e01b10cd0cad50179f68fe8c8fed1c86e4a1

Sean Robertson commented

2020-11-29 22:25:35 +01:00

Added subscriber: @seanr

Sean Robertson commented

2020-11-29 22:25:35 +01:00

I can confirm that @jenkm's fix in D9662 works well. 2.92 was utterly unusable without it, but it now appears to be performing even better than it did previously with the fix.

I can confirm that @jenkm's fix in [D9662](https://archive.blender.org/developer/D9662) works well. 2.92 was utterly unusable without it, but it now appears to be performing even better than it did previously with the fix.

Brecht Van Lommel commented

2020-11-30 13:44:34 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Brecht Van Lommel closed this issue

2020-11-30 13:44:34 +01:00

Brecht Van Lommel self-assigned this 2020-11-30 13:44:34 +01:00

Samuel Sebastian Tekrenius commented

2021-04-30 20:36:48 +02:00

Added subscriber: @AgentSam-2

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

Continuous grab is broken 2.92.0 Alpha macOS #82870