Hi, can you set the cursor outline shape in Krita to "tilt outline" and see if the tilt angle shown also jumps in the same way?

Which one of WinTab and Windows Ink do you have enabled in the tablet settings inside Krita?

(In reply to Alvin Wong from comment #1)
> Hi, can you set the cursor outline shape in Krita to "tilt outline" and see
> if the tilt angle shown also jumps in the same way?
> 
> Which one of WinTab and Windows Ink do you have enabled in the tablet
> settings inside Krita?

It happens with "Circle Outline" and "Tilt Outline" as well. I have Wintab selected as Windows Ink doesn't work properly in Krita 5.

I think we will need a tablet log to diagnose this issue. Please try following step 5 under https://docs.krita.org/en/contributors_manual/user_support.html#gathering-information to get a tablet log of a pen stroke showing the flickering behaviour.

Here is the log file and the text output from Tablet Tester (just tipping the test area a few times).

http://www.argfx.at/upload/Cintiq27QHD_Krita_Logs_01.zip

Thanks. Just judging from the tablet log (and you can see it for yourself), the tilt angles `xTilt` and `yTilt` seems pretty normal and smooth, so it seems that the pen input is not the problem here. I don't have a clue what might be happening. This needs to be checked by someone else.

For the record I don't see similar behaviour on my Surface Pro 2017 using WinInk.

(P.S. The tablet tester is useless for this because it doesn't log tilt angle.)

To be sure I checked it with Windows Ink as well (I usually use WinTab) and problem is there as well. 

Earlier today I filed a bug about the brush tip not registering a brush stroke when the pen just tips the surface without moving. Maybe the two issues are related somehow?

I tried to reproduce this bug on both, Linux and Windows and I couldn't get exactly the same issue. The only "suspicious behavior" I could find was that the brush sometimes does some kind of "unwinding" when the stylus releases the canvas. It looks like some smoothing algorithm triggers somewhere, though I don't remember any :)

Let me know if you need any more tests or data from me.

Do you have this flickering on just simple hover, without touching the table surface? Or when releasing the stylus?

I have found the cause jump-on-release issue, but I don't see how it can happen on just normal hover...

It only happens when tipping the surface. Hovering is fine.

I checked again, and the flickering happens when lifting the brush off of the surface indeed. So when I lift the brush, the cursor flickers back to its neutral position for a split-second and the goes back to the tilt direction again. So you might be right with your assessment.

Looking at the code, I have a feeling like you should also have rotation jumps when "Stabilizer" is enabled. Could you check that?

Not sure what you mean exactly. When I enabled stabilizer with pen tilt activated, the flickering still happens,  as it also happens without stabilizer as well. When I deactivate pen tilt, set the rotation in the brush tip section and then use stabilizer - there's no flickering.

Okay, just from mere looking at the code, the tilt rotation shouldn't work with the stabilizer in hover mode at all, but it does :) Anyway, I'll look at it now

Why? I think the cursor should always display the pen tilt correction properly so that you know what rotation you will start with when you put the pen down.

Yeah, I know, I was only joking, sorry :) The source code is a bit complicated here, so from the first glance it doesn't look like it should work, but it works :) I'm working on making it work all the time without any jumping.

Alright. Cheers for looking into it.

Mind that the Surface Pro 2017 digitizer does not provide tilt information when the pen tip is not pressed down.

Git commit a8e0e4f4037f8998ba01a33e3dad7e87046e2b33 by Dmitry Kazakov.
Committed on 23/11/2021 at 13:36.
Pushed by dkazakov into branch 'master'.

[not for 5.0] Fix flickering of tilt-controlled brushes on tablet release

When the stylus leaves the tablet surface a pair of
KisToolPaint::activatePrimaryAction()/deactivatePrimaryAction() events
is delivered to the tool. They request update of the tool outline, but
since there is no pointer event available, this outline was generated
via a non-tilted/non-rotated fallback case. It caused a visible flickering
while painting.

The patch implements multiple things:

1) It severely refactors KoPointerEvent to allow copying and storage
   of such events. Now the class became "much more simple and
   understandable" (c) due to the usage of boost::variant2 (which
   is technically a C++17's std::variant).

2) Now the tool can request the last delivered pointer event from the
   canvas via KoToolBase::lastDeliveredPointerEvent().

M  +277  -130  libs/flake/KoPointerEvent.cpp
M  +48   -47   libs/flake/KoPointerEvent.h
M  +11   -0    libs/flake/KoToolBase.cpp
M  +7    -0    libs/flake/KoToolBase.h
M  +13   -8    libs/flake/KoToolProxy.cpp
M  +2    -0    libs/flake/KoToolProxy.h
M  +4    -1    libs/flake/KoToolProxy_p.h
M  +0    -1    libs/ui/canvas/kis_tool_proxy.cpp
M  +3    -43   libs/ui/input/kis_input_manager.cpp
M  +4    -1    libs/ui/tool/kis_tool_freehand_helper.cpp
M  +1    -1    libs/ui/tool/kis_tool_paint.cc
M  +1    -5    libs/ui/widgets/kis_scratch_pad_event_filter.cpp

https://invent.kde.org/graphics/krita/commit/a8e0e4f4037f8998ba01a33e3dad7e87046e2b33

Hi, Andreas!

The bug should be fixed now! I have kicked off nightly builds, please test when this build has completed:
https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/1544/

Sadly, this patch is too dangerous to be backported to Krita 5.0, so, most probably, it will be available only in Krita 5.1.

HEUREKA!!! You're a genius. Works like a charm.

This deserved an immediate donation. Cheers.

And I'm working on the nightly builds anyway. So I don't mind that it's not included in 5.0.