Page MenuHome

Multi-View: Fix Side by Side/Top Bottom mode bad cursor behaviour

Authored by Julian Eisel (Severin) on Jun 12 2015, 12:11 PM.



Pretty basic but also pretty solid working hack to fix the bad cursor
offset behavior in Side by Side/Top Bottom modes.

Idea is basically to offset the mouse coordinates before sending.

Diff Detail

rB Blender

Event Timeline

Julian Eisel (Severin) retitled this revision from to Multi-View: Fix Side by Side/Top Bottom mode bad cursor behaviour.Jun 12 2015, 12:11 PM
Julian Eisel (Severin) updated this object.
Julian Eisel (Severin) updated this revision to Diff 4392.

Noted other events e.g. from trackpads change event->x/y as well, but can't check atm, will do that later.

A few issues:

  • The mouse cursor is drawn for the top (or left) eye only. That leads to a ghost/blinking cursor when viewing in a stereo display
  • Shift + F (camera navigation) is no longer working

Shouldn't that be only for the side-by-side and top-bottom modes? What does this affect the UI?

Re: cursor is drawn for the top (or left) eye only:
This doesn't change the cursor drawing it only changes the coords used for handling. If you move the cursor to the bottom half e.g. it is still in the bottom half. Also note that this patch works for both halves of the screen, so the handling always matches what the user sees, regardless of which half of the screen he is in (should really make comments in wm_stereo3d_mouse_offset_apply more clear :S)

However, I'm afraid that fixing the blinking cursor isn't that easy. Googled a bit but seems like cursor drawing is low level OS code which we can't influence (except of disabling it completely/changing appearance). Maybe this is just a limitation we have to live with :| (although we could do crazy things like using a custom cursor set that we can draw a second time, but don't think that's a good solution either)

Re: Camera navigation no longer working
Good catch, yeah. For such cases I had the idea of adding event->save_xy values which would always be the real mouse coordinates, so we can access them for corner cases like that one (would also make it possible to fix the WM_cursor_grab_disable issue described below)

PS: Not easy to describe these things, hope you get what I mean :D


Issue is that below WM_cursor_grab_disable has the mouse_ungrab_xy parameter which is used to change the cursor position before unhiding it, but since this is done on GHOST level it needs the real screen coordinates, which we currently can't calculate (tried it without any luck). Result is that the cursor is set to a completely different position than what is drawn on screen.

In the else block below it uses WM_cursor_grab_disable without setting mouse_ungrab_xy meaning it's just reset at the center of the button so behavior has only changed a little but we get rid of the cursor reappearing at wrong position glitch.

The 'software' cursor would be the correct way to go indeed. But it may be too much work, and maybe your patch can provide a bad provisory solution.

Just to illustrate the issue with your approach:
Right now, not only the cursor shows only for one eye, but it will be perceived as twice as big as it should be.

Well even if we had a software cursor, the interface handling would still be done using window space mouse coordinates so we still had the same offset we have now if I'm not missing something. If we had a complete software cursor pipeline where we were able to offset the cursor drawing position, we'd have jumping cursors while entering/exiting the Blender window, entering/exiting multiview, etc - changing the cursor position without user input is really bad UX wise and should definitely be avoided. Instead, just a second cursor in the other window half should appear.

All proper fixes I can think of would consist out of two parts:

  • The drawing part (draw cursor with half size and draw 2 ones)
  • The handling part (converting events from window space to multiview space)

Whereby the second part is tackled with this patch. I agree that this isn't the solution for all problems, but think it is the first part of it.

@Dalai Felinto (dfelinto), what's your current opinion on this, still think it's okay as a fix.

@Julian Eisel (Severin) alright, but how about having a patch with the drawing part too? Is this something you plan to tackle eventually?

Changes in event system are always a bit risky, even if this patch shouldn't touch non-multiview mode. Will commit after release, just to be safe.

Committed rB80444effc62ac9, as it's also going to affect the ongoing HMD support implementation.