ALyman's picture

The MouseDevice.Move event

The OpenTK.Input.Mouse.Move event has been commented out since r1303 (2008-05-04), with the log message "Temporarily remove MouseDevice.Move event, due to issues with deltas when the mouse stops moving."

Are these delta-related issues still existent? If so, are there steps to reproduce? I haven't personally noticed anything that looked wonky after uncommenting it in my local copy while running on Win32 or OpenSUSE.

[Moderator edit: trimmed title.]


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Yes, the issues remain. The problem is that no event indicates the end of a mouse movement, which means deltas are never reset to zero when the mouse stops moving.

One solution would be to rework the mouse drivers to rely on polling. The other solution is to completely remove the delta properties from the MouseDevice.

Ultimately, this will depend on whether the GameWindow will be rewritten to rely on Windows.Forms internally, as discussed recently.

ALyman's picture

Are we talking about MouseDevice.XDelta and MouseDevice.YDelta? If so, the source seems to indicate that the values returned from those have nothing directly to do with mouse movement. AFAICT, they're currently returning the axis-specific change in position since the last time that particular ._Delta was called.

If this isn't the correct behavior (and I can't think of any real use for it), perhaps .XDelta and .YDelta are currently useless? If they're the only thing stopping the potentially useful .Move event, perhaps your second suggested solution would be the best route, at least in the short-term?

I'm more than willing to work up a patch for it, if you'd like. I'm fairly committed to having the .Move event while still tracking OpenTK's trunk.