Hi, @abrahams!

Dropping of the events might be a dangerous thing. The problem is that the two events "with the same coordinates" are actually different because they have different pressure

TabletPress      btn: 1 btns: 1 pos:  747, 663 gpos:  785, 747 hires:  784.714, 747.402 prs: 0.406647 Stylus Pen id: 9148331722651 xTilt: 34 yTilt: 4 rot: 0 z: 0 tp: 0 "	
TabletMove       btn: 0 btns: 1 pos:  747, 663 gpos:  785, 747 hires:  784.714, 747.402 prs: 0.713587 Stylus Pen id: 9148331722651 xTilt: 34 yTilt: 2 rot: 0 z: 0 tp: 0 "

It means that the user will not be able to start a sharp heavy line from the very beginning. It will become faded. I once did such workaround for Genius tablets, which were sending the events in parts, and the users complained about it :(

Are you able to reproduce the issue on your computer? Could you check what exactly happens in the smoothing algorithm? As far as I remember it should handle zero-segments correctly...

Hi Dmitry, thank you for reviewing this. I completely overlooked that the events have different pressure. Of course dropping the first event is incorrect here, the correct starting pressure should be 71%.

I don't know where the code for handling a repeated point is located. I couldn't easily find where repeated coordinates would be handled, if there was a special case for it.

Something that caught my eye in the smoothing code (which gave me the idea for this patch) is that the tangent for the first dab of a stroke is computed differently from the rest of the stroke.

In kis_freehand_helper line 481:

// Now paint between the coordinates, using the bezier curve interpolation
if (!m_d->haveTangent) {
    m_d->haveTangent = true;
    m_d->previousTangent =
        (info.pos() - m_d->previousPaintInformation.pos()) /
        qMax(qreal(1.0), info.currentTime() - m_d->previousPaintInformation.currentTime());
} else {
    QPointF newTangent =
        (info.pos() - m_d->olderPaintInformation.pos()) /
        qMax(qreal(1.0), info.currentTime() - m_d->olderPaintInformation.currentTime());

    paintBezierSegment(m_d->olderPaintInformation, m_d->previousPaintInformation,
                       m_d->previousTangent, newTangent);

    m_d->previousTangent = newTangent;
}

Hi, Michael!

The code you found looks really related. What if you add a check for info.pos() and m_d->previousPaintInformation.pos() be the same and, if not, just skipping initialing m_d->haveTangent? It should help...

Hi, @abrahams!

Do you need any help with this bug? :)

Hi Dmitry: yes, I was replicating this bug on my Surface Pro 3, but my custom builds have been broken for a while, so I can't replicate it on my machine reliably anymore. It would be good if you took this over.

(Just pondering, eventually it might be nice to have a test where you can feed in some custom events and see if it produces any glitches...)

Hi, @abrahams!

I tried to reproduce the bug. I applied this testing patch P36 to generate a spurious tablet move event on every tablet press event, but I didn't manage to get any weirdness in line stroke. Could you please add a video of the problem and/or test the patch (here: P36)?

The only consequence of the event repetition is that previousTangent becomes null, which cannot cause any visible problems.