Page MenuHome

RGB Curve Node: cursor jumps back (OSX only)
Closed, ResolvedPublic


System Information
OS X 10.8.5 NVIDIA GeForce GTX 780M 4096 MB

Blender Version
Broken: 2.68 - 2.74 4e7ef3f
Worked: 2.63

Short description of error
On mouse release (after curve adjust), cursor jumps (or appears) back on place of initial click in RGB Curve node.

Exact steps for others to reproduce the error

  • add RGB Curve node
  • drag and move curve to adjust
  • on mouse release curve is adjured, but mouse pointer jumps back to initial click

I don't have all versions of blender now so I can't say when exactly this behavior occurred, but possibly with cycles RGB node.
2.63 and older versions works OK (this version of cycles is without RGB Curve node), 2.68 is first one I have on computer that works with this issue.

I use tablet, but I don't have a pen on it :)
I tried to disconnect tablet … the same behavior.

If you need some more info I can post I'm one big ear. Thank you

Event Timeline

filip mond (vklidu) set Type to Bug.
filip mond (vklidu) created this task.
filip mond (vklidu) raised the priority of this task from to Needs Triage by Developer.

Hi, this is strange behavior. some questions.

  • Does this happen on every curve? (try spot lamp falloff curve for example... or texture painting falloff curve)
  • Does this happen after resetting to factory defaults?
  • If you have access to another system, can you redo the bug elsewhere?
  • Are you using any kind of special/non-standard input software/drivers. (we had reports that blender fails with for eg).
filip mond (vklidu) added a comment.EditedMay 5 2015, 11:28 AM
  • This seems like it happens on every curve

  • I tested on factory setting
  • Same behavior on other two iMacs. I don't have another OS like Linux or Windows, but from your reaction I see you don't have this issue.

(iMac 27" OS X Yosemitte 10.10.3 ATI Radeon HD 5750 1024 MB and iMac 24" OS X 10.8.5 ATI Radeon HD 2600 Pro 256 MB)

  • I don't use any "non-standard" inputs, I use only Wacom tablet, but the as I wrote - same behavior is on iMacs without any special inputs.

Now noticed one more think (see video) when I move slider, then on mouse release pointer appears on first click position - as with curve manipulation, and in this case it looks helpful - we don't have to move back pointer into slider area, and that is why I didn't post it earlier as a bug.
But small problem here is - if I click again (to move slider) without any mouse pointer movement, than node jumps :) If I move (even a bit) mouse pointer it doesn't happen.

Here is a behavior in 2.63 for reference. Pointer stay at a point of release (curve or slider).

Somethink that maybe helps identify error:
I use Screenflow for recording, in this app I can activate "Click effect" on mouse click.
In videos you can see - click effect is not there for clicks with mentioned issues, but visible in test in 2.63 where it works. So also this app see differences with mouse click to move node and move curve.

Nobody with OS X can't reproduce this?

My wife notebook MacBook Pro, OS X Yosemite 10.10.2, Intel HD Graphics 4000 1024 MB.
It is the fourth Mac with this issue.

I can reproduce on macbook pro with iris pro.

Bastien Montagne (mont29) triaged this task as Normal priority.

Changed to unconfirmed state, we are sorry, but we have to be able to reproduce an issue to investigate it. If no dev can do so within two weeks, we’ll have to close the report…

Arg! sorry, read 'can’t' instead of 'can' :(

This option is broken on Macs since the beginning. Mouse warping or hiding is against the Apple UI guidelines, which is why it works so bad I guess.

How did the OSX team here accept it? Easy to see how broken it is:

  • get a panel with 2 number buttons next to each other
  • drag value of left button to right, move mouse on virtual position of the other button. you see it hilight.
  • release mouse, click. Input goes to the wrong button.

I'm in agreement with OS X guidelines, and against manipulating mouse positions. Nice for some people, but then only behind a user pref.
Why is it bad? It kills muscle memory, it makes you lift up the mouse all the time to put it back. So in the end you don't even win anything (as in speed of use).
I can see why some like it though, especially if you navigate around with a mouse-lift habit.

@Ton Roosendaal (ton),

  • There's no wrapping/mouse position manipulation involved in this particular case. If OSX can not survive hiding the mouse cursor then well....
  • This _is_ and option, which is called "Continuous Grab" (User Preferences -> Input -> Continuous Grab). It was enabled by default quite some time ago. Discussion about whether it was right or wrong decision is a separate topic, this report clearly shows a bug which is to be addressed.

EDIT, well actually it might be wrapping when shift is holded down. Not sure if any wrapping happens without shift tho.

Sergey: in contrary. It wraps the mouse in this case too (and it fails to).

Sorry, seems like my english skills are not enough to clearly understand the discussion now, so only one note to ton's post "This option is broken on Macs since the beginning." - as mentioned in the bug description - it worked well in 2.63 and older versions on Mac.

Campbell Barton (campbellbarton) renamed this task from RGB Curve Node – cursor jumps back to RGB Curve Node: cursor jumps back (OSX only).Jun 1 2015, 9:06 AM
Campbell Barton (campbellbarton) raised the priority of this task from Normal to Confirmed, Medium.

@filip mond (vklidu), this is maybe caused by the default activated Continuous Grab and the Update in 2.66 (see Release Notes). You can deactivate it in the preferences (Input Tab)

@Leon Eckardt (Leon95): Thank you. You are right, disabled "Continuous Grab" keeps cursor behaviour OK.
But "Continuous Grab" is super useful thing ... any chance to find solution?

If its because of continuous then it is known todo any reason we are keeping this open as a bug a not a to do?

@Aaron Carlisle (Blendify), this is not the same as continuous grab issue, even when continuous grab is working properly (for view-port operations) this glitch still happens.

Fixed both the original reported issues with curves and the button focus issue explained by Ton.

The main issue is that contrary to what the comment in the code said, the cursor position must be set again when continuous grab ends, the same as on other platforms. Most of the changes are fixing some inconsistencies in coordinate space conversion to make that work.

I know it is not a chat here, but I have to say ... Thank you million times for this fix :)