flxzt
Pen Input prediction
Please submit only one feature request in one issue!
If it is UI/UX related, don't post how a single aspect of the UI should be changed, rather in which use-case you felt
the UI is lacking or should be improved.
When I switched from Windows to Linux, I noticed a significant increase in pen input latency (4-5x). After reading for a while, I found out that Windows uses an algorithm to predict the current pen position. I was wondering, if it is possible to implement something similar in rnote.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I know that part of the problem is my hardware (surface pro 7) as Linux uses polling unlike Windows for pen input. I already disabled smoothing in lib input and tried full preemption made it actually worse).
Still, there is at least a 2x difference between rnote and oneNote both on windows wich might be reduced by this.
Additional context
Add any other context or screenshots about the feature request here.
From my brief test of linux on surface devices, support for pen is not totally there. In particular, I'm pretty sure the linux version has a lower poll rate on the pen (maybe 120 Hz max vs the 240 Hz-ish I measured on windows).
From rnote's point of view, for each frame gtk sends all events that occurred between the previous frame and the new one in one go (it's not rare to have 2+ or 4+ pen events here, depending on the poll rate of the pen/screen refresh rate). I'm pretty sure this means we don't get intermediate events to anticipate the next frame here. I've not done a full latency analysis to get the full timing info + where the latency occurs though, but it probably doesn't help here.
With the modeled path modelling option, for each pen input, we update the current smoothed path (that's final) + we give an extension to it that's only valid until the next event that catches up between the end of the smoothed path and the current last position of the pen. Smoothing is done with a mass/damper dynamical system.
But we don't go further than the pen position (so we don't technically predict to the next pen input). This way the smoothed path doesn't appear to lag behind the pen.
