On (some?) Wacom tablets (here: Cintiq tablet and MacOS), if you keep a button pressed, lift the pen far from the drawing surface and touch it down, the coordinates of the cursorDown event will be incorrect.
Instead the current mouse coordinates are reported, which usually are where the pen was previously lifted. If we start drawing at such coordinates, we get strange long lines.
Another shortcoming is that in this input sequence, the button press is not recognized anymore, reporting buttons "1" instead of "3" for keeping button "2" pressed.
I don't see any way of getting the required information, so that quirk is unchanged.
Note: i maked this as "draft", as i could only test this on our specific hardware.
On (some?) Wacom tablets (here: Cintiq tablet and MacOS), if you keep a button pressed, lift the pen far from the drawing surface and touch it down, the coordinates of the cursorDown event will be incorrect. Instead the current mouse coordinates are reported, which usually are where the pen was previously lifted. If we start drawing at such coordinates, we get strange long lines.
This clip demonstrates the issue:
https://github.com/decker-edu/decker/assets/1302738/1d243e8b-3080-429f-8a63-f9cc08064119
Therefore, we should not use startStroke() in the "down" event handler, but only trust the coordinates from "move" events, which appear to be correct.
Interestingly, the official Wacom HTML demo suffers from the same problem.
Another shortcoming is that in this input sequence, the button press is not recognized anymore, reporting buttons "1" instead of "3" for keeping button "2" pressed. I don't see any way of getting the required information, so that quirk is unchanged.
Note: i maked this as "draft", as i could only test this on our specific hardware.