Adjust output speed on the distance travelled instead of input speed?

[sphh]

Your YeetMouse is great: I can finally use my trackball, which used to be very, very slow!

Still I wonder if it were possible to use the distance travelled instead of the input speed to adjust the output speed. The idea is, that if I don't move the mouse far from its starting point, I want precise positioning of the cursor. If I move the cursor past a certain threshold, it should be assumed that I want to reach a different area on the screen – and to do that, the mouse should travel faster.

Obviously the mouse should slow down again when the destination is reached, e.g. the mouse stops/slows down …

Using this approach, I don't have to speed up the trackball that much to get the same result!

Is that possible? What do you think?

[AndyFilter]

Hey thanks, I'm glad you found this program helpful. I'm not sure if I understand the request correctly. But if I do, then it's impossible unless I add Neuralink integration, at which point using a "cursor" becomes... unnecessary to say the least.

So, if you mean something like this:

(or circular areas rather than rectangular, so the distance is the same for all directions)
Then it technically is possible, although would be very annoying in practice I think.

And if you mean what I think you mean, which is - changing the mouse acceleration based on the intent of the target cursor destination, then it's impossible. As the program can't possibly know where you want to move your mouse at the start of the motion.

And going off with just your first sentence - "distance travelled instead of the input speed", then, yea. That would be possible. But it can mean a couple of different things.
Example: We start moving, and the movement continues for (let's say) 1 second and 1000 pixels in one direction, along the path, the acceleration grows with the distance from the centre point.
This has an issue of determining when does a movement end? Is it after the driver receives an empty movement frame [0,0]? After 100ms with no mouse input? After a "significant" direction change? There's a lot of variables here that would make:
a) the implementation very troublesome,
b) the usability very volatile (a correct set of parameters (angle, cooldown time, distance, scaling factor, even screen size would play a role).

If I missed the point, please correct me. But I'm worried that it might just not be possible, and you're best off using some Jump (or similar) curve.

[sphh]

You are absolutely right that YeetMouse cannot know where I want to move the mouse to.

Your sketch is exactly what I mean. Let's try to explain it with a sort of algorithm:

1. Define a time constant T and a distance constant D.
2. When the mouse moves, save the starting position p of the mouse together with the current time t.
3. Recall the position p' of the mouse at the time t-T.
4. If the distance |p-p'|>D, speed up the mouse, otherwise leave the speed untouched.

Obviously there are some variants to the implemantation details:

• Don't use |p-p'|<D, but |x-x'|<D or |y-y'|<D.
• Use a FIFO buffer for the mouse positions, which can store all mouse positions in a time interval T.
• Use a sophisticated acceleration curve as a function of the distance travelled.

That's just an idea …

[AndyFilter]

You are absolutely right (...)

Hello, Anthropic Claude!

About the algorithm - it's not exactly what my sketch suggested, but still very much doable.
So in the case of an acceleration function like this:

$$ A(t)= \begin{cases}% 1 & \text{if $|p(t)-p(t-T)| < D$}\\ accel(|p(t)-p(t-T)|) & \text{otherwise} \end{cases} $$

Where $A(t)$ is the acceleration function of time, and $p$ returns a mouse position at a given time $t$.

The hardest part (at least implementation-wise) is the function $p$ that returns the position of the mouse at a given time. This would have to be a dynamic array of sorts as it needs to have O(1) lookup time, it also somehow needs handles missing / delayed frames. Also, getting the global mouse position in the kernel might be surprisingly difficult. But all that aside, it's a cool idea, unfortunately the effort that would have to be put into this is tremendous compared to its "value" (amount of people that will use this).

Btw. one might consider a way to make the function A to instead be of class $C^1$ (continuously differentiable) the definition then could for example be:

$$ A(t)= interp(1, accel(|p(t)-p(t-T)|), \frac{|p(t)-p(t-T)|}{D}) $$

Where $interp$ is the interpolation function (can be even defined the same way as the acceleration function - by the user; or just linear).
This approach guarantees a smooth transition between the close and the far regions of the screen. It just "blurs" the inner edge.

keep in mind - both these approaches have a radial characteristic $\bigcirc$, rather than the rectangular $\square$ that I drew earlier. If instead one would prefer the the second option the approach you provided would suffice: $|p(t)_x-p(t-T)_x|&lt;D \vee |p(t)_y-p(t-T)_y|&lt;D$ instead of $|p(t)-p(t-T)| &lt; D$.

So, in the end - it is possible, but with the huge backlog that this project already has, and very little time that I have, unfortunately I doubt this will ever be implemented. But, here you can shine. If you manage to write a simple, sensible and clean code for this the way I described (or better), then I'll be more than happy to review those changes and possibly merge them!

P.S. thanks for an opportunity to use some LaTeX haha, I haven't touched it for a while, and I was getting rusty. Good to warm up a bit from time to time, especially considering I might need to use it more soon...