flxzt
Erase faster to increase eraser size
Trying this, I feel like there is some additional work to be done.
~~There is no upper limit to the eraser size. When switching from the pen to the eraser, the initial size can sometimes be too large, even exceeding the visible canvas size (and delete a whole document instead of staying as a small eraser). It might be worse on some devices (an initial small displacement over a very small timestep will give a velocity estimation with very large error bounds, and that timestep might be 1/60 s on some pens down to 1/480 s. Hence the potential very large overestimate even with the initial smoothing). This should be fixed. An upper bound on speed or eraser size should also be here. Maybe we can try to re use the ink stroke modeler for this (but output the velocity estimation instead) or do some kalman based filtering (where we can model the error on the speed estimation and act on it if necessary).~~ Edit : issue from below. However setting an upper bound might not be a bad idea anyway.
The other thing I'm wondering is that on other software that scales the eraser size depending on speed, the actual behavior is not doing a speed estimation and scaling the eraser size with respect to that. There is some inertia to it, or some way to lock or decrease smoothly or in steps the eraser size when the speed decreases. It might be more akin to a "erase faster means getting the next eraser size and locking it to that size until you stop or slow down" situation. Realistically, we're not obliged to follow suit on that, but we should come up with a behavior that makes sense and will satisfy the original feature request.
In the video shown in the issue, the eraser seems to step in size as the user moves quickly for a while, then gradually step down once the user has stopped moving. This could be implemented either as smoothing over a very long period of time, so the eraser needs to be moved quickly for a while in order to get to its full size, or by checking if the eraser has been moving fast for at least X ms, then stepping up the size. Which one do you think would be better?
I'm still getting the same issue with the start size being sometimes too large then going down. I will try to spend some times logging things to check where this comes from.
Doing things when the user stops moving is also a little harder to do. With pens, you always have some jitter hence events continue happening (but events stop happening if you stop with a mouse). This is the same issue I had with #1175 (needing a separate thread to call changes in the future and being cautious not to have more than one event fire at the same time because of it). But maybe in that case that's okay not to do that (as you trigger the change of size with movement, not stopping the pen)
Maybe we can use a better designed speed to eraser size function (somewhat of a stepped function so you get the same size for some range of speed) ?
The other idea I had was to add a size to the EraserMotion structure and have it be updated by some well chosen function like size = f(size, speed) so that we get some hysteresis-like behavior (lock/converge to some size levels and change value significantly only for large/slow speed).
Honestly I don't have a perfect answer, though I want to check whether if we can get what we want with the current strategy (smoothing). I don't know what's the better approach here.
The eraser now needs to exceed some minimum speed in order to start scaling up, and scaling is now a stepped function with hysteresis. The exact values to trigger stepping up/down can be tweaked, so we'll want to play around with those to get something that feels good to use. It might even be a good idea to expose them as config options for the user, since different users will probably have different speeds at which they'll want to trigger eraser scaling.
We still need some way of detecting a lack of motion, since events stop firing when you hold still, even on a drawing tablet. This will need to be faster than the long press detector you already have, but the underlying logic should be similar.
Look at https://github.com/flxzt/rnote/commit/f20775cab7bddacbc2086cbda0b4424b4634c140#diff-4dd2da25347b4ca65437059e5072856b3085e9c029be3a91a1a6b140fabaf47aR493 to make it compile.
Sorry, it's been a while since I've looked at the PR. I still get the bug of the eraser being very large when the pen touches the screen (do we need or can we estimate correctly the speed when the pen is hovering ? maybe there is something happening here ?)
I think I need to take the time to debug this properly (and maybe extract some representative raw input sequences that we can use to fine tune the program. I wonder if it's of interest to add something like that to the dev menu for future uses as well : record raw/smoothed inputs for pen and eraser and save to a file/json for analysis). To be clear, I'm not asking you for this, I'll probably do a separate PR for this.
I think what might help is calculating pen speed as part of input handling, so we can filter the input more, and possibly use it for other features later down the line.
The bug was caused by the eraser bounds still using the estimated speed instead of the added_width. It now works correctly. Maybe we can fine tune parameters a little bit?
As far as calculating speed higher in the input handling code, it may not be worth estimating speed for nothing. I think it's the right place for it. We may mutualize some code between here and the ink stroke modeler in the future if we are to implement a finer velocity estimation method (though I think this already works pretty well)
https://github.com/flxzt/rnote/blob/f7adb2acc0277f549db5f0de8764d1dff9ea6989/crates/rnote-engine/src/pens/eraser.rs#L190-L191
Missing a self.motion.reset().
I'm not convinced we need to estimate speed while the eraser is in proximity mode. If we don't, what we can do is change the EraserState to have
Down(Element, EraserMotion)
Doing that means we don't have to do a reset as the EraserMotion will only be there if we are in the Down mode.
Edit : The jump in speed when the pen touches the screen seems to come from a weird timing of events on my device, when my pen touches the screen an event is sent with a very short time delta compared to the rest