https://bugs.kde.org/show_bug.cgi?id=383407
Alvin Wong <alvinhoc...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://phabricator.kde.org | |/T8050 --- Comment #12 from Alvin Wong <alvinhoc...@gmail.com> --- (In reply to Calle Laakkonen from comment #10) > Hi, the developer of Drawpile here. > I'm using Krita's Wintab event handler in the latest master branch version > of Drawpile. I copied the mouse mode hack from Qt source and it seems to > work. [...] > > Adding these lines didn't seem to break anything on my computer and Wade > also reported that it fixed mouse mode for him (and didn't break pen mode.) (In reply to Calle Laakkonen from comment #11) > One Drawpile user just reported this: > https://github.com/drawpile/Drawpile/issues/568 > > Looks like there was a good reason the mouse mode hack was left out of > Krita. If the tablet coordinates are offset from the mouse coordinates so > that the offset is very close to the m_absoluteRange threshold, it will > result in random jagged lines being drawn when the threshold is crossed. Ah, thanks for the info! The report you linked to seem to show an offset between the cursor and the tablet though. I suspected there is an error in calculating the WinTab coordinates, which I've made a patch here [1](https://phabricator.kde.org/D10685), but I couldn't verify without affected hardware and drivers. Back to the hack from Qt: I have a problem with it, which is that it can go wrong in a few ways: - The tablet event may snap to the system cursor if it lags behind the WinTab position. - It could cause the jumps when there is just a slight offset in the WinTab coordinates calculation, just enough to cause it to jump at the middle of the screen. - When in mouse mode, if the absolute WinTab position happens to be close enough to the screen position of the system cursor, it may cause a hiccup in the line when it decides not to snap to the system cursor for a moment. The worst thing is that it decides on its own. In Qt it is possible to configure the threshold via a command line option, but still... I would prefer an explicit option to either use the system cursor position or not. Using the system cursor position for drawing is also just awful; the tablets have a higher-than-mouse precision for a reason! Anyway, I plan to start working on this along with a bunch of other WinTab-related stuff after Krita 4.0 is released. -- You are receiving this mail because: You are watching all bug changes.