Replies: 1 comment 7 replies
-
Ok that is really weird. On web I just forward the movementX and-Y from the mousemove event, so maybe I somehow skip some events, I have to look into that. Or do you happen to be using touch input? In that case I compute the delta myself from current and previous position so there could be some inaccuracies there. Fortunately, I can easily get the actual position of the mouse, so I will expose that along with the delta for the mouse move event as well as investigate the accuracy of the delta. |
Beta Was this translation helpful? Give feedback.
7 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@asny
Observed mouse movement through
Event::MouseMotion {delta}
(as in examples/texture) seems to be underreporting pixel delta, especially when the mouse is moved quickly.This effect isn't observable in the demos because it's hard to tell how much rotation should map to a mouse movement. I'm implementing a click-and-drag view interface with an orthographic projection, in which the rendered images should have a fixed position to the cursor as it's dragged across the screen. This does work occasionally, but usually it appears that the delta reported with the MouseMotion event is smaller than it should be, and the graphics don't move far enough to keep up with the cursor, This effect seems to occur more with fast mouse movements, and more in the web version than in the desktop version.
I'm trying to find a mouse motion handling technique that will demonstrate the expected behavior, either just to prove the idea of the underreported motion or as a permanent workaround. Is there an easy way to get cursor position, instead of delta, at the time that a MouseMotion event is handled?
Beta Was this translation helpful? Give feedback.
All reactions