jittery display when using mouse drag with Continuous Drag ON #39094

Macbook Pro 15"

16Gb 1600 ddr3 ram

nvidia geforce GT 650m 1024 MB

OSX 10.8.5 12F45

Blender 2.7 release candidate
2014-03-05 Hash 19f7f9a

When using middle mouse button to rotate the 3D environment in 3D view, encountering a vibration in the movement where the 3D grid and mouse vibrate at a very fast speed. This occurs on the default file. It's more obvious the slower you move the mouse (again with middle-scroll wheel clicked to rotate 3D view.)

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps

Changed status to: 'Open'

Added subscriber: @msmick

#39826 was marked as duplicate of this issue

#39709 was marked as duplicate of this issue

Added subscriber: @LukasTonne

This sounds very much like a hardware or driver issue.

Have you tried "Load factory defaults"? Are your drivers up to date? Maybe try a different mouse?
We need at least a test file (startup.blend, by default in /Users/<username>/Library/Application Support/Blender/2.70/config/startup.blend on OSX).

I thought so too, I was reluctant to report, but I have 2.69 installed as well on the system and this doesn't happen. I will try to supply a video recording. I can't screen capture the problem unfortunately. I am not able to try with a different mouse unfortunately. With matched user preferences settings with 2.69 Im still experiencing the jittering.

The issue appears to be caused by the user preferences checkbox of "Continuous Grab' (under input section of preferences) Continuous grab was the default setting for both RC1 and RC2 on Mac x64 version.

Now with 'continuous grab' unchecked, I'm getting smooth behavior on rotating the 3D view. The jittery movement of the objects on screen and grid and even ghosted mouse cursor for whatever reason goes away.

I had suspected this was NOT a hardware issue because 2.69 installed it was not occurring. This was because the option was not checked in 2.69.

Once I tested in 2.69 the with continous grab checked the jittery movement did in fact occur on 2.69. It's related to the movement of the mouse rather than the button action. This is confirmed because I can select the default cube, press G and constrain to x,y,z where I can let go of buttons and the jittery movement happens.

Added subscriber: @ThomasDinges

@ThomasDinges Sounds like this might be related to retina stuff perhaps? Are you able to test on a mac?

Added subscriber: @mont29

Thomas, assigning to you in hope you'll be able to confirm or not the issue?

Added subscribers: @pancake-manicure, @jensverwiebe, @ideasman42

◀ Merged tasks: #39709.

Added subscriber: @OlliPikkarainen

◀ Merged tasks: #39826.

Re-assigning to you for now, since this definitively seems to be OSX-related?

link from #39826: http://smoothmouse.com/forum/topic/309-jumpy-mouse-in-blender-with-continuous-grab/

@msmick, are you using SmoothMouse?

Changed status from 'Open' to: 'Archived'

no response, closing.

Changed status from 'Archived' to: 'Open'

Since there are enough similar reports, keeping it open.

Hey Campbell, glad to see this re-opened. I can confirm that it happened to me with SmoothMouse activated, with continuous grab enabled. One thing to point out is that for any users of SmoothMouse, continuous grab is enabled by default, which breaks Blender for anyone who doesn't know how to fix it.

@pancake-manicure: smoothmouse calls its self an experimental project, and it has problems with games too http://dae.me/blog/1526/what-to-expect-from-smoothmouse/

So it's just an unsupported configuration.

However it seems theres still some problems on OSX, even without smooth-mouse.

Added subscriber: @Ton

No it's 90% sure our fault. In 2.75 rc I still get problems with the cont grab here. Warping mouse pointers is fishy in OS X.
I don't have time to test this unfortunately...

Added subscriber: @fjuhec

I don't use smoothmouse but I use Screen Sharing to connect from Mac to Mac and this issue happens when remotely connected.
Continuous Grab and Screen Sharing don't mix well at all.

@fjuhec, using any remove desktop is likely to fail too (VNC, screen-sharing etc...)

Can anyone redo this problem with a 'normal' configuration?

(That is regular mouse, no customized drivers, no remote desktop)

@ideasman42 , yes, of course there are issues with other remote desktop applications on other OS but only when the mouse gets out of the 3D view region and goes to the other side.
In Mac it's much worse, it works bad from the start when the mouse is still inside the region. This works ok on other remote desktop and OS. I think it indicates something and remote desktop is an easy way to see the issue.

Removed subscriber: @jensverwiebe

Added subscriber: @Blendify

Can this be closed since no one seems to be able to reproduce without using things like desktop sharing and smooth mouse?

Changed status from 'Open' to: 'Archived'

We really need a reproducible test case. I have access to an OSX systems but cant redo.

This is also working for many OSX users it seems.

If there is something we can reliably redo, this can be re-opened,
but closing for now.

Hi,
I know it's been closed but I have been investigating the issue and found the cause to be that when other software manipulates the mouse (like Remote Desktop or Smooth Mouse) while Blender is also doing it when mouse grab is enabled, [event deltaX/Y] no longer has a valid value as it now has an accumulated delta because of conflicting mouse positions (Blender is forcing the starting position or warping it so the event delta is relative to the original or warped position, not the previous one).

Here is a patch that somehow fixes the issue, at least in the systems I tested with Remote Desktop, not tested with Smooth Mouse or retina Mac.
Maybe it needs further investigation but it might be a good starting point if you want.

diff --git a/intern/ghost/intern/GHOST_SystemCocoa.h b/intern/ghost/intern/GHOST_SystemCocoa.h
index 3d6b40e..d216378 100644
--- a/intern/ghost/intern/GHOST_SystemCocoa.h
+++ b/intern/ghost/intern/GHOST_SystemCocoa.h
@@ -296,6 +296,8 @@ protected:
 	 * Needed because cocoa event delta cursor move takes setCursorPosition changes too.
 	 */
 	GHOST_TInt32 m_cursorDelta_x, m_cursorDelta_y;
+	GHOST_TInt32 m_cursorPrevDelta_x, m_cursorPrevDelta_y;
+	float m_cursorPrevLocation_x, m_cursorPrevLocation_y;
 	
 	/** Multitouch trackpad availability */
 	bool m_hasMultiTouchTrackpad;
diff --git a/intern/ghost/intern/GHOST_SystemCocoa.mm b/intern/ghost/intern/GHOST_SystemCocoa.mm
index b9686e5..6d2c2dc 100644
--- a/intern/ghost/intern/GHOST_SystemCocoa.mm
+++ b/intern/ghost/intern/GHOST_SystemCocoa.mm
@@ -349,6 +349,10 @@ GHOST_SystemCocoa::GHOST_SystemCocoa()
 	m_modifierMask =0;
 	m_cursorDelta_x=0;
 	m_cursorDelta_y=0;
+	m_cursorPrevDelta_x=0;
+	m_cursorPrevDelta_y=0;
+	m_cursorPrevLocation_x=0;
+	m_cursorPrevLocation_y=0;
 	m_outsideLoopEventProcessed = false;
 	m_needDelayedApplicationBecomeActiveEventProcessing = false;
 	m_displayManager = new GHOST_DisplayManagerCocoa ();
@@ -1311,6 +1315,29 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr)
 					grab_mode = GHOST_kGrabDisable;
 				}
 
+				NSPoint mousePos = [cocoawindow mouseLocationOutsideOfEventStream];
+				GHOST_TInt32 x_mouseDiff = mousePos.x - m_cursorPrevLocation_x;
+				GHOST_TInt32 y_mouseDiff = mousePos.y - m_cursorPrevLocation_y;
+				// Check if the mouse has been hijacked by an external program like Remote desktop
+				// When the mouse is hijacked mouseDiff is not 0 but there are cases where the hijacked event
+				// is split in two, that is handled by cursorPrevDelta
+				if ((x_mouseDiff != 0 || y_mouseDiff != 0 || m_cursorPrevDelta_x != 0 || m_cursorPrevDelta_y != 0)
+						&& window->getCursorGrabModeIsWarp()) {
+					grab_mode = GHOST_kGrabDisable;
+					window->setCursorGrabAccum(0, 0);
+					if (x_mouseDiff != 0 || y_mouseDiff != 0) {
+						m_cursorPrevDelta_x=x_mouseDiff - [event deltaX];
+						m_cursorPrevDelta_y=y_mouseDiff + [event deltaY];
+					} else {
+						m_cursorPrevDelta_x=0;
+						m_cursorPrevDelta_y=0;
+					}
+					m_cursorDelta_x=0;
+					m_cursorDelta_y=0;
+				}
+				m_cursorPrevLocation_x=mousePos.x;
+				m_cursorPrevLocation_y=mousePos.y;
+
 				switch (grab_mode) {
 					case GHOST_kGrabHide: //Cursor hidden grab operation : no cursor move
 					{
@@ -1329,7 +1356,6 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr)
 					}
 					case GHOST_kGrabWrap: //Wrap cursor at area/window boundaries
 					{
-						NSPoint mousePos = [cocoawindow mouseLocationOutsideOfEventStream];
 						GHOST_TInt32 x_mouse= mousePos.x;
 						GHOST_TInt32 y_mouse= mousePos.y;
 						GHOST_TInt32 x_accum, y_accum, x_cur, y_cur, x, y;
@@ -1352,7 +1378,6 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr)
 						y_accum += -[event deltaY]-m_cursorDelta_y; //Strange Apple implementation (inverted coordinates for the deltaY) ...
 						window->setCursorGrabAccum(x_accum, y_accum);
 						
-						
 						//Warp mouse cursor if needed
 						x_mouse += [event deltaX]-m_cursorDelta_x;
 						y_mouse += -[event deltaY]-m_cursorDelta_y;
@@ -1365,6 +1390,8 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr)
 						//Set new cursor position
 						window->clientToScreenIntern(x_mouse, y_mouse, x_cur, y_cur);
 						setMouseCursorPosition(x_cur, y_cur); /* wrap */
+						m_cursorPrevLocation_x=x_mouse;
+						m_cursorPrevLocation_y=y_mouse;
 						
 						//Post event
 						window->getCursorGrabInitPos(x_cur, y_cur);
@@ -1375,7 +1402,6 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr)
 					default:
 					{
 						//Normal cursor operation: send mouse position in window
-						NSPoint mousePos = [cocoawindow mouseLocationOutsideOfEventStream];
 						GHOST_TInt32 x, y;
 						
 						window->clientToScreenIntern(mousePos.x, mousePos.y, x, y);

Hi, I know it's been closed but I have been investigating the issue and found the cause to be that when other software manipulates the mouse (like Remote Desktop or Smooth Mouse) while Blender is also doing it when mouse grab is enabled, [event deltaX/Y] no longer has a valid value as it now has an accumulated delta because of conflicting mouse positions (Blender is forcing the starting position or warping it so the event delta is relative to the original or warped position, not the previous one). Here is a patch that somehow fixes the issue, at least in the systems I tested with Remote Desktop, not tested with Smooth Mouse or retina Mac. Maybe it needs further investigation but it might be a good starting point if you want. ``` diff --git a/intern/ghost/intern/GHOST_SystemCocoa.h b/intern/ghost/intern/GHOST_SystemCocoa.h index 3d6b40e..d216378 100644 --- a/intern/ghost/intern/GHOST_SystemCocoa.h +++ b/intern/ghost/intern/GHOST_SystemCocoa.h @@ -296,6 +296,8 @@ protected: * Needed because cocoa event delta cursor move takes setCursorPosition changes too. */ GHOST_TInt32 m_cursorDelta_x, m_cursorDelta_y; + GHOST_TInt32 m_cursorPrevDelta_x, m_cursorPrevDelta_y; + float m_cursorPrevLocation_x, m_cursorPrevLocation_y; /** Multitouch trackpad availability */ bool m_hasMultiTouchTrackpad; diff --git a/intern/ghost/intern/GHOST_SystemCocoa.mm b/intern/ghost/intern/GHOST_SystemCocoa.mm index b9686e5..6d2c2dc 100644 --- a/intern/ghost/intern/GHOST_SystemCocoa.mm +++ b/intern/ghost/intern/GHOST_SystemCocoa.mm @@ -349,6 +349,10 @@ GHOST_SystemCocoa::GHOST_SystemCocoa() m_modifierMask =0; m_cursorDelta_x=0; m_cursorDelta_y=0; + m_cursorPrevDelta_x=0; + m_cursorPrevDelta_y=0; + m_cursorPrevLocation_x=0; + m_cursorPrevLocation_y=0; m_outsideLoopEventProcessed = false; m_needDelayedApplicationBecomeActiveEventProcessing = false; m_displayManager = new GHOST_DisplayManagerCocoa (); @@ -1311,6 +1315,29 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr) grab_mode = GHOST_kGrabDisable; } + NSPoint mousePos = [cocoawindow mouseLocationOutsideOfEventStream]; + GHOST_TInt32 x_mouseDiff = mousePos.x - m_cursorPrevLocation_x; + GHOST_TInt32 y_mouseDiff = mousePos.y - m_cursorPrevLocation_y; + // Check if the mouse has been hijacked by an external program like Remote desktop + // When the mouse is hijacked mouseDiff is not 0 but there are cases where the hijacked event + // is split in two, that is handled by cursorPrevDelta + if ((x_mouseDiff != 0 || y_mouseDiff != 0 || m_cursorPrevDelta_x != 0 || m_cursorPrevDelta_y != 0) + && window->getCursorGrabModeIsWarp()) { + grab_mode = GHOST_kGrabDisable; + window->setCursorGrabAccum(0, 0); + if (x_mouseDiff != 0 || y_mouseDiff != 0) { + m_cursorPrevDelta_x=x_mouseDiff - [event deltaX]; + m_cursorPrevDelta_y=y_mouseDiff + [event deltaY]; + } else { + m_cursorPrevDelta_x=0; + m_cursorPrevDelta_y=0; + } + m_cursorDelta_x=0; + m_cursorDelta_y=0; + } + m_cursorPrevLocation_x=mousePos.x; + m_cursorPrevLocation_y=mousePos.y; + switch (grab_mode) { case GHOST_kGrabHide: //Cursor hidden grab operation : no cursor move { @@ -1329,7 +1356,6 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr) } case GHOST_kGrabWrap: //Wrap cursor at area/window boundaries { - NSPoint mousePos = [cocoawindow mouseLocationOutsideOfEventStream]; GHOST_TInt32 x_mouse= mousePos.x; GHOST_TInt32 y_mouse= mousePos.y; GHOST_TInt32 x_accum, y_accum, x_cur, y_cur, x, y; @@ -1352,7 +1378,6 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr) y_accum += -[event deltaY]-m_cursorDelta_y; //Strange Apple implementation (inverted coordinates for the deltaY) ... window->setCursorGrabAccum(x_accum, y_accum); - //Warp mouse cursor if needed x_mouse += [event deltaX]-m_cursorDelta_x; y_mouse += -[event deltaY]-m_cursorDelta_y; @@ -1365,6 +1390,8 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr) //Set new cursor position window->clientToScreenIntern(x_mouse, y_mouse, x_cur, y_cur); setMouseCursorPosition(x_cur, y_cur); /* wrap */ + m_cursorPrevLocation_x=x_mouse; + m_cursorPrevLocation_y=y_mouse; //Post event window->getCursorGrabInitPos(x_cur, y_cur); @@ -1375,7 +1402,6 @@ GHOST_TSuccess GHOST_SystemCocoa::handleMouseEvent(void *eventPtr) default: { //Normal cursor operation: send mouse position in window - NSPoint mousePos = [cocoawindow mouseLocationOutsideOfEventStream]; GHOST_TInt32 x, y; window->clientToScreenIntern(mousePos.x, mousePos.y, x, y); ```

Added subscriber: @zlaughingdragon

Even though this thread was closed the problem remains relevant.

I noticed this issue recently in my Blender version 2.75, and found this thread. Thank you for the continuous scroll fix. However, I like the feature so I was messing around figuring out answers.

It does in fact seem to have something to do with the Mac display and/or multi display configuration. Using a 40" 1920x1080p HDTV as a second monitor (main) I was getting MAJOR jitters. When disabling and then re-enabling the aforementioned continuous scroll feature, the jitter was reduced to a small vibration.

At this point I closed my macbook pro, disabling the built in display. With continuous scroll ENABLED, the issue disappeared immediately. 100% smooth motion.

Things to note:
I do not have Smooth Mouse.
I am 90% sure I do not have a retina display.
//16gb of ram, mid-2012 macbook pro.
Samsung 40" HDTV//

Added subscriber: @jroo-4

I'm having the same issue. Here's what I can offer:

It happens whether or not I use an external monitor.

I do have software installed for my Mouse (Steel Series Sensei) but stutter happens whether or not the software is running.

The only thing that seems to fix the issue is disabling Continuous Grab.

Blender 2.78b
MacBook Pro (Retina, 13-inch, Early 2015)
2.9 GHz Intel Core i5
16 GB 1867 MHz DDR3
Intel Iris Graphics 6100 1536 MB

Thanks.

Added subscriber: @MattWolcott

Same here. I just got a new mouse (Logitech G502) and Blender became totally unusable during any middle button drag. Rotation view, holding Shift to move... also any mouse drag to scale parameters, they would all just jump all over the screen. HUGE movements.

I thought I would have to get another mouse, but disabling Continuous Drag solved the issue for me.

Blender 2.78c
OSX 10.12.3
NVIDIA GeForce GTX 980 Ti + GTX 980

Added subscriber: @RobertS

I just tried Blender 2.79b on my mother's 2014 iMac with High Sierra installed.

I brough two modern Steelseries mice with me, and both of them had jitter which rendered Blender unusable while middle dragging (or actually also scale + z + z dragging).

Then I connected a probably 15 yeard old Logitech mouse I found in a closet and used that instead. No problem.

The modern mice work on the rest of OS X, but not Blender it seems?

I maybe need to start a new bug/thread, but I am still seeing this issue sometimes, even on very latest Blender on MacOS or even more so, with remote desktop/Parsec on Windows 10.

3DS Max doesn't show the same issue, only seems to be Blender.

I tried to disable continuous Grab, which helps, but I can still get stutter/jutter. If I Zoom/Pan the viewport, its shaking a bit.

Often what happens on MacOS , is my mouse/keyboard can suddenly stop responding, or like middle mouse or alt or something gets stuck.. is very odd.

I'm running Blender 3.4.1 now, on Windows 10, using Parsec and seeing the issue.
I could test Remote Desktop to see if similar or not.

@mattli911 best open a new report with exact details on what happens.

Also, be sure to check a daily build as well as the latest stable.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

jittery display when using mouse drag with Continuous Drag ON #39094