Page MenuHome

Fix T83930: Walk navigation using tablet - repositioning the stylus rotates the view
AbandonedPublic

Authored by Vincent Blankfield (vvv) on Dec 18 2020, 6:39 PM.

Details

Reviewers
None
Group Reviewers
Restricted Project
User Interface
Maniphest Tasks
T83930: Walk navigation using tablet - repositioning the stylus rotates the view
Summary

Problem

When using a tablet in a walk navigation, lifting and repositioning the stylus is handled as if the stylus has been moved to the new position in range. This makes the view rotate a lot, making the walk navigation only usable when the stylus doesn't leave the range height.

Proposed solution

First of all, we need to reset walk->is_cursor_absolute in walkEvent() when going from absolute to relative. Because currently, as long as a tablet has been used once, during the walk modal running, walk->is_cursor_absolute will stay absolute (even if a relative pointing device is used afterwards).

Second we'll need a (reliable) relative position event when a tablet goes out of range so the absolute coordinates get re-centered each time the tablet goes in range. For that we can send a dummy mouse move event on WT_PROXIMITY, when not inRange.

Not sure if this (second part) is an acceptable solution, maybe there's a more elegant one. Also, I have no idea how this behaves on the other platforms. I tested this with WinTab only. Triaging help on other platforms is appreciated.

Note that the proposed fix doesn't work well if the stylus went in range not over the Blender window. Those events may also be handled if this is a way to go.

Diff Detail

Repository
rB Blender

Event Timeline

Another strategy to consider for the Ghost part of this commit: add a cursor offset when the cursor is grabbed while a tablet has left/reentered range. This may or may not fix the out of window issue.

I haven't reasoned through the consequences of either change entirely.

Thinking a bit more I think accumulating while grabbed is the better solution. It would also fix workflows like moving a grabbed object.

If you need reference code you can check processCursorEvent in GHOST_SystemWin32.

Thanks for looking into this issue. I'm sorry, but I don't think I understand the proposed solution.

In any case, this patch was never meant to be a final fix. The idea was to create a bug report with some diffs as illustrations. I've only posted it as a patch because I've been asked to. And apparently you have a better fix for this in mind. So there's no reason of keeping this one open.

By the way, about this fix not working when the cursor enters from outside. I wrote that line when creating the bug report without really checking that edge case. After looking at it more closely, I noticed that it can be divided into two separate issues:

  1. The cursor enters the active Blender window from outside (make Blender not maximized; enter walk navigation; move the cursor into the Blender window from outside using tablet). Doesn't make much sense to recenter coordinates on the edge, though making the view not to jerk to the side at full speed would be nice.
  1. Blender is not an active window (activate walk navigation; Alt+Tab to another small window; use either mouse or tablet over the viewport). This case is unrelated to the fix in question. It affects both mouse and tablet and is quite an obscure workflow.