I think I cracked it. It only happens when using a Pro Pen 2 from Wacom on my end. As to why? It could be a couple reasons.
The pro pen 2 introduced several improvements, and one of them was a higher polling rate. The pen driver would report position more times per second. Perhaps this is throwing out the panning distance calculations? Could also be a lower polling rate, my Cintiq is 185hz and my mouse is 1000 (or 125 for testing).
Another thing could be Wacom’s drivers are bad, but I don’t need to tell you that. The only argument against that is Krita is the only program I can find that suffers this badly from them.
It’s extremely obvious here, where I overlay all the frames and compare them mouse vs tablet panning.
I have an idea, with my limited programming knowledge and having never looked at the source code:
I think that when Krita wants to draw the next frame of panning, the first thing it does is ask for the last reported position of the mouse cursor.
Depending on when it calls for that position in relation to the last time the mouse polled, this may be several milliseconds in the past, or less than a millisecond. Since these aren’t synced, it created the gaps we see.
Now why does it work with a 1000hz mouse smoothly?
Because when Krita wants to draw the next frame and asks for the last mouse position, it will always get one less than a millisecond in the past and this inconsistency no longer exists.
I have opened a bug report at 439106 – Low pointer polling rates cause inconsistent frame 'timings' in functions tied to pointer movement.