Change movement_x and movement_y to f64

[AdoHTQ]

This fixes #520 . I am not sure if this is the most reliable solution as I am not sure of the source of the problem in the first place. The update speed of the cursor is back to it's original speed and there are no more warnings in the console.

[KalokaK]

I have independently discovered #520 and have independently come up with a simmilar fix, mine was just to remove movement_x and movement_y entirely. This has fixed all the lag and its a joy to use now.

movement_x and movement_y are not used anywhere in the codebase as far as I can tell so removing them is better than casting to float, specifically because we should consider this note on MouseEvent from MDN (28.01.2026):

Warning

Browsers use different units for movementX and screenX than what the specification defines. Depending on the browser and operating system, the movementX units may be a physical pixel, a logical pixel, or a CSS pixel. You may want to avoid the movement properties, and instead calculate the delta between the current client values (screenX, screenY) and the previous client values.

If the values are to be kept from future updates, maybe we want to do the following (from the same MDN page):

The movementX read-only property of the MouseEvent interface provides the difference in the X coordinate of the mouse pointer between the given event and the previous mousemove event. In other words, the value of the property is computed like this: currentEvent.movementX = currentEvent.screenX - previousEvent.screenX

If you really want to read them from the browser, casting to f64 does seem like the best option, as this will also allow for integer offsets. A pull request could also do this server side, discarding the client values. But dropping them entirely also lowers package size (very, very, marginally).