you could check if maybe some security software is interfering? We had it before that someone’s Razer mouse utility ran off with the tablet events, and sandboxie is known to be troublesome as well(and there’s someone who had issues with f.lux too), but other than that, I wouldn’t know.
I made an exception in my Avast and still nothing. No pressure sensitivity and the cursor still freezes upon being removed from the tablet surface.
Edit: Welp, I figured out what the problem is. Krita does not like my tablet being used in “mouse mode” which is a real shame because I absolutely cannot work in pen mode. That is incredibly disappointing. :\
I really like the 4.0 features planned, especially Python scripting with a plugin manager. 
I not too experienced with 2D animation and I am learning and playing around. I was watching an inbetweening tutorial on Youtube and one thing I noticed the animator do was to take pages off the pegs to make it easier to do the inbetweens.
So if you were animating on twos and, 1 and 5 were your extremes and 3 the inbetween, you keep 1 on the pegs, 5 and 3 come off the pegs goes on top of 1 and gets rotated and moved to align some parts of the draw.
Can you go off-pegs or out of pegs in Krita? This was a function I saw was present in TVpaint, from googling around, you could translate and rotate a frame in respect to the frames in the layer, draw on it and return it back to normal once you were done drawing. If this is not possible am sure it would be a cool function to have.
I’ve always been curious about this mouse mode thing in tablets. Is there any special advantage that one can’t have in the regular pen mode?
it’s about cursor control for display : tablet relation&ratio
while regular mode is absolute (same/equal mapping used on tablet as is on display, beware when buying hardware),
mouse mode is relative (independent of where you put your pen on tablet, you start where the cursor is located on the display, no problem with display:tablet ratio, especially for dual+ display sets)
i work in relative reality & state of mind 
It can give more precise control. but I personally don’t like it, it shakes off my landmarks.
No. Uhm… I guess make a wishbug on bugs.kde.org or make a topic on the forum? Animation is mostly being optimised right now.
As for the tablet stuff, the same guy that implemented win8 pointer events is looking into a mouse mode of sorts, but as far as we can tell, all programs using mouse mode are unable to use subpixel precision(cause mouse coordinates have no subpixel precision). So you will always need to use smoothing with it.
I tried it with an open mind. Didn’t work. The cursor moves erratically at times.
Would have been great, so I didn’t have to set up my dual displays in Linux via the terminal every time I upgrade the system. But I see the point.
An issue related to my Wacom Intuos Pro 4 Large tablet. I posted it on the KDE forum as well (https://forum.kde.org/viewtopic.php?f=139&t=141894&p=381605#p381605) but no answer?
Basically, when I draw in Krita with a simple 12px inking or pencil brush, the actual mouse cursor is a bit ahead of where the stroke is being drawn. It also experience this in Photoshop, PhotoLine (stroke stabilizer) and OpenToonz.
But not in ClipStudio. There’s never an offset in ClipStudio: where the cursor is, that’s where the stroke is drawn.
I’ve spent hours trying to find a solution, but it seems unfixable: I’ve turned off the other screens, switched between QT and Wintab (SHIFT option), entered manual values… Nothing works to get rid of that offset.
When I draw a bit faster the offset increases.
And yes: I turn off all stroke stabilization, which only exacerbates the issue. I work on a 7016x4961px canvas, but I also tried a lower resolution 1920x1080. No difference. At 256x256px the offset seems slightly less obvious.
Also, at the 7016x4961 resolution zoomed out I cannot draw quick strokes without Krita lagging like crazy: a simple 12px stroke takes almost a 1/4-1/2 second to catch up. No issues in ClipStudio.
I WANT to work in Krita, but the cursor offset leads to less clean and controlled strokes compared to ClipStudio.
Help anyone? 
The offset is probably caused by Windows’ triple buffering (vsync) of the screen content and the filtering performed by the Windows Wacom Driver. The Windows triple buffering cannot be disabled except for exclusive full screen applications (e.g. games).
On KDE and other desktop managers on Linux, vsync on the desktop can be disabled, and additionally the tablet driver is not as filtered as the one on Windows; both of these (especially the former) generally leads to a potentially more direct drawing experience on Linux.
I haven’t tried it but I bet that Clip Studio doesn’t show the mouse cursor while drawing, correct? This reduces the perceived lag, because it removes the mismatch between the screen pointer (which gets drawn first in Windows) and the line being drawn (the last thing in the UI stack getting drawn).
You can do something similar in Krita by setting the cursor shape to “no cursor” and enabling the outline shape while painting if you haven’t already. The lag will still be there but there will be no visual mismatch between the line being drawn and the mouse cursor. Hopefully this will improve your drawing experience.
Thanks s12a - that is very helpful. I turned off the cursor shape, and I get a much better ‘feel’ - I never considered turning off the actual cursor while drawing. It was quite distracting.
“problem” solved!
The extreme lag when drawing quick strokes with a thin brush on a zoomed canvas still happens. I can live with that, though.
The latter might be instant preview? It is kinda problematic with small brushes.
Also, we now have a 3.0 release candidate, it has a ton of bugfixes.
I forgot to mention it because I have some real life things that preoccupy me.
No, I turn off instant preview when working with small brushes. Even turned off all cursors - still the same. I tested the 3.3 release candidate: same issue, although it updates the stroke in segments.
Crazy thing is, the more I zoom out, the stronger the lag. At 6.2% it literally takes up over a second to draw the stroke. Mouse or Wacom: same result. The longer the stroke I draw, the longer the lag and time it takes to catch up with the mouse cursor.
When I zoom into the canvas, the lag becomes almost logarithmically less and less. Weird. It’s as if Krita is having trouble digesting all the mouse/wacom data, and interpolation between positions causes the lag.
Whoop, Krita 3.3, with angle support to cope with bad intel drivers, windows 8 pointer events for surface pro, and a whole load of bugfixes.
https://krita.org/en/item/krita-3-3-0/
Herbert, maybe your device has an issue with the scaling? Try one of the other options in the settings, under display, like maybe just bilinear or trilinear is much easier on your device?
Don’t know how many people use G’MIC filters, but the basic ones are not available like bevel (inner, outer), emboss, etc. I mean if Krita is working on vector and text development, they’re going to have to add these essential filters for stylizing texts. Luckily, Gimp is there for such features.
If I may ask, when you use Krita on other machines, do those show the same slight offset between mouse cursor and where the stroke draws while drawing? When I draw very slow there is (hardly) any offset. When I just draw a dot, no offset. The quicker I draw, the larger that offset becomes. The cursor is always ahead of the stroke.
On my Asus Epe121 slate with Wacom digitizer the position where I draw on the screen is also always ahead of the actual stroke. In Krita, in MyPaint, OpenToonz: doesn’t matter. Two very different devices, same offset.
I suppose it is just part of how it works.
Right-click the layer and pick Layer Styles. All that stuff should be in there.
Thanks, xrg. Seems not the same as Gimp separating the effect as layers, so the original layer can be turned off.
Layer styles are similar to modifiers in Blender. You can make changes and the style will update. You can enable/disable them by clicking the “FX” icon on the layer.
GIMP won’t have layer styles until version 3.2 according to their roadmap.