Above all I'm not requesting anything specific to the devs. I just wanted to write a post explaining this a bit clearly and see if there's someone on the forum having the same issue with me.

My spec :
OS : Windows 7 (x64)
CPU : Intel(R) Core(TM) i7-2600
VGA : Radeon RX 560 Series
RAM : 16G
Tablet : Wacom Intuos Pro



I'm not a coder, so I could be completely wrong but I think when I'm painting it seems that the calculation of printing indivisual brush tips on the canvas follows the path of brush's position change(1), and the brush follows the cursor(2).

I think the most of 'Performance improvements' has been done so far has shortened the delay of (1),
And you get this extra delay(2) when you enable 'Desktop Window Manager Session Manager' in Computer Management > Service. (* It doesn't seem to be specific to Windows 7, but you can't easily disable DWMSM and above... >https://forum.kde.org/viewtopic.php?f=281&t=142768#p383595) It behaves as if the stabilizer feature is on.

Disabling it makes the brush strictly stick to the cursor and get rid of the sloppiness.

With DWMSM :


Without DWMSM :


I'd be glad if you can check if it's the case for you if you're using Windows. (If you have no delay 'at all' whether it's enabled, then it's just my system in particular having problem.)

Yes, it's a known issue that aero causes smallish delays. We have to put up with it or use Linux... On KDE Plasma, it's still easy to disable all the desktop effects, and that makes a nice difference.

boudewijn wrote:Yes, it's a known issue that aero causes smallish delays. We have to put up with it or use Linux... On KDE Plasma, it's still easy to disable all the desktop effects, and that makes a nice difference.

1 Is there no delay at all between the cursor and the brush on Linux?
2 Mind if I ask if you have any plan on investigating this issue(It doesn't have to be right now, just saying.)? Since Windows 10 is the last Windows number not being able to disable DWMSM will go permanent.

All investigations point to us not being able to do anything about it on our side. Otherwise we'd have fixed it already :s

One thing that might help a bit is to disable the outline cursor and only use a hardware cursor. Though that doesn't really fix it, it's only cosmetical.

tayloryoung wrote:[...]I'd be glad if you can check if it's the case for you if you're using Windows. (If you have no delay 'at all' whether it's enabled, then it's just my system in particular having problem.)

I have this too. It's inherent to the Windows operating system. It's due to the compositor's vsync/triple buffering, which cannot be normally disabled for regular applications. If you check out more in detail with a video recorded at the frame rate equivalent to your display's refresh rate, the brush outline lags exactly 2 or 3 frames behind the mouse pointer. A possible solution to this would be if Krita could optionally operate in Windows as a full-screen application and toggle vsync off like many 3D games can do. I think a while back some changes in the nightly builds resulted in this accidentally occurring during full-screen operation, but it was buggy and got disabled shortly after it was introduced. It got also discussed briefly on IRC.

Otherwise, the only option left besides using Windows 7 until it's supported would using Linux with a window manager that allows to disable easily desktop composition. This coupled with the generally less filtered pen tablet driver makes for a more direct drawing/painting experience than on Windows, even with the compositor and/or vsync enabled.

I've just checked other painting applications(CSP, SAI...) and it was not specific to Krita.
I guess you're right, it's hard to 'fix'. (* Krita seems to be more laggy with ANGLE renderer in my system BTW, but it's not any important...)

I'm really wondering. Is there no such sort of delay on Linux? Maybe I should consider using Linux at least for painting. It's a small issue but affecting my work...

If you're using a Radeon GPU, make sure that "OpenGL Triple Buffering" and "Wait for Vertical Refresh" are not enabled under Global Graphics options in Radeon Settings. These seem to affect Krita negatively last time I checked.

The delay is not as severe on Linux if vertical synchronization is on, and can be mostly eliminated by disabling desktop composition, which turns it off completely, in addition to other minor overheads. Disabling it of course comes with the drawback of screen tearing, but it isn't too important while drawing/painting.

I'm really wondering. Is there no such sort of delay on Linux?

There is; but far less if you use a KDE Plasma desktop without composition, XFCE or OpenBox and a lot of smaller D.E. The worst lag I had was with Unity when Ubuntu had that. GNOME and KDE with effect are both OK nowaday especially if the graphic driver is well supported. I also keep desactivating the brush outline while doing inking for a more real time experience. I wrote this about that: https://www.davidrevoy.com/article339/w ... ita-cursor

tayloryoung wrote:I'm really wondering. Is there no such sort of delay on Linux? Maybe I should consider using Linux at least for painting. It's a small issue but affecting my work and I can't cosmetically conceal it since it's not a psycological thing.

I'm a **** painter, but because I'm regularly switching between OS'es I have noticed this myself, and yes, on Linux, with X11 and the KDE Plasma desktop with kwin's desktop effects turned off, this problem is really gone. It's not psychological, and maybe if we figure out again how to make Krita's (actually Qt's) full-screen mode disable aero, we might be able to bypass it on Windows. But, yeah... In the noble cause of shadows and stuff, Windows has done its users a bad turn.

Thanks to everyone replied to this topic. I genuinely appreciate it.

Ah, the 'desktop effects', 'desktop composition' you mentioned must have meant some linux equivalent of window's DWMSM, Aero;

tayloryoung wrote:Ah, the 'desktop effects', 'desktop composition' you mentioned must have meant some linux equivalent of window's DWMSM, Aero;

Yes, exactly.