Make speed input work sensibly for touch drawing

Carsten Hartenfelsrequested to merge
hartenfels/krita:feature/touchdrawspeed into master

When touch drawing, Krita doesn't receive any hover events when the finger is in the air, unlike with a mouse or a tablet pen. That means the usual handling of distance and speed doesn't work, since the inputs stop where the last stroke left off and start again when the finger is pressed down again, rather than continually being updated as the pen or mouse is moving. That leads to the speed input being effectively garbage at the beginning of a touch stroke.

This commit resets the speed and distance inputs when starting a paint operation. That doesn't give the same results as with a mouse or pen, but at least it makes the inputs predictable and useful. The same is also done when updating the outline so that it doesn't incorrectly flicker to the wrong size at the beginning of a stroke. (At least not more than it does for any other input, there's always a brief full-size flicker when starting to draw.)

Here's a visual from Drawpile user mebbie that reported this to me:

Krita touch draw visual Drawpile touch draw visual

Test Plan

  • Create a brush with its Size dependent on Speed with the standard linear curve.
  • Touch paint with it.
    • Previous behavior: the brush starts out with a speed dependent on where the last stroke left off, which basically means it has some kind of blotch at the beginning.
    • New behavior: the brush starts out with a zero speed.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
  • Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Merge request reports