@dkazakov In the commit message:

The problem is that on Windows the tablet events are coming in bunches,
not uniformly. Therefore any timing-based smoothing system will not work
out of box.

May I ask whether this is still an issue with current master and patched Qt 5.6.1? Or was this some issue related to event compression of Qt which may already be fixed in Krita?

I tried logging the timestamps of the pen events from my Wacom Intuos Pen & Touch, and they seem to be spaced rather evenly and frequently with intervals of 5-8ms. But I guess it could be different with other tablets with bad drivers?

Note: I logged the events in KisToolFreehandHelper::paint using the timestamps from KisToolFreehandHelper::elapsedStrokeTime.

On a related note, KisToolFreehandHelper::Private::strokeTime is a QTime, maybe I should try QElapsedTimer here instead?

Ok, so I tried disabling that event uniform timeframe code (maybe not properly) and yeah I can see choppy bent segments. I don't know whether that means the problem described in that commit is still here, or that there is something wrong with how I tried to disable that without reverting the commit.

Even with the commit, I do still seem to get bent lines sometimes, and much more often when I use the mouse. I guess it's due to the frequency of mouse events being much lower than my tablet, therefore the output is going to suck anyway unless heavy smoothing is used.

@dkazakov May I know how you decided on the default values for stabilizerSampleSize?

Hi, @alvinhochun!

The non-uniform sample rate is not related to Qt's compression. It is a different thing. The Wintab packets are queued in the system queue until the application can processes them. The second queue happens in the stabilizer, which is basically a time-based sampling of the events. And on slower GPUs and bigger canvases, window update can execute for quite a long time (10-12ms), therefore blocking the event processing. Therefore we can get 2-3 events processed one after another, with time difference of 0ms, which breaks stabilizer.

And for some reason on Windows this problem is much more severe than on Linux. I cannot remember why.

For the record, on irc:

<dmitryK|log> windragon: well, I was not the original implementer of it :) As far as I know, the original idea was to sample the tablet position every millisecond and calculate the weighted average
<dmitryK|log> windragon: which will obviously never work unless you run the stuff in real-time-guaranteed environment
<dmitryK|log> windragon: (every timer delay creates "bendness" of the lines)
<dmitryK|log> windragon: so I just implemented a high-level emulation of that sampling.
<dmitryK|log> windragon: the sample rate 50ms was set to the highest event delay I got locally. This number ensures if at least one new event will ocme during the sample