Photoshop use system cursor as brush outline from my understanding (looks like that), while krita use software rendered outline.
Workaround (kind of):
Turn on “cursor” in setting can at least feel a little more responsive, as it add a system cursor under your pen.
The brush outline can also quickly toggle on/off with shortcut (need assign yourself) and leave system cursor when doing line art
Thanks for the reply. Which settings are they exactly? I already have the brush shape disabled during stroke.
System cursor:
Setting > Configure krita > General > Cursor > Brush Cursor Icon for system cursor.
Personally, I prefer “small circle”.
Quick toggle brush outline:
Setting > Configure Krita > Keyboard shortcut and search “toggle brush outline” and assign a shortcut
OR
Setting > Configure Toolbar, search “toggle brush outline” and add it to the toolbar.
The action will show as plain text when adding to toolbar, so I prefer using keyboard shortcut.
Edit: It reminds me Ralek’s reply to another post that also asking brush outline lag. [Solved] Stylus kind of Lags in Krita? - #11 by Ralek (#11 and #13)
You’re not crazy, as much as many users here will try to make you think you are. Krita has a significantly large pen delay that Krita purists will refuse to acknowledge turns away new users, or even exists in the first place, but it can be fixed. I abhor brush latency and managed to fix it or at least lessen it on my system back when I was on Windows.
In the Nvidia control panel, go to 3d settings and add Krita as a program if it’s not there. In the settings, there is a setting for ‘triple buffering’, make sure it is forced off. There is also a setting for “vertical sync”, make sure that is either ‘off’ for best latency or ‘fast’ for okay latency but no tearing.
Krita will, even when drawing, regularly spit out 100-400fps. How it manages to feel so delayed and jittery all the time compared to every other program is something I have researched significantly.
The only significant lag I’ve had while using Krita for many years is with my latest i9 Intel system and once I switched Krita to OpenGL that went away.
@kacart yeah, this is what works for me too but I thought AMD prefered OpenGL and Intel otherwise, but i guess I’m wrong.
To the OP, I might not have solutions for you but I can provide you some reference from my experience, I hope it helps in some way or the other.
Firstly this is the system i use, it is quite mid, i think: Ryzen 5 2600 coupled with Radeon 6700 XT and 32 GB RAM.
So, I also had responsiveness issue with Krita and messed around with the settings. Not just brush stroke lag but also navigation lag (pan, zoom and rotate canvas) and UI lag. My solution was changing the API to OpenGL instead of the default (auto that is set to DirectX11, could be different depends on system) and tick the texture bufering off.
I also had some system crashes, not just the app but the whole system so i have to press reset button and restart my PC. But this never happen again until I set the brush frame rate to 60 fps instead the default 100 fps.
After these two changes my experience with Krita improved a lot, I then went ahead and set the RAM allocation higher to 70 percent and lower the CPU usage to 10 from 12.
Note, I am still expriencing some lag and skips but way way less that i think i can live with it.
Another note, i am not at all a tech guy and i don’t 100% understand what I was doing and why the changes happen. I am just glad it turned out well for me. There might be documentation about this somewhere, but I am not sure that i will understand them even when I read it. Haha. But yeah, I wish someone can explain these better than me.
@Ralek I never thought of checking to the card’s control panel. Let me try that too. Thanks for the insight.
Can’t offer any real solution but the info might be interesting nonetheless: I’m working on a Cintiq Pro 24 and macOS 13.2 with a M1 and it’s actually snappier than PS to me. Had some crashing issues though, but they were solved.
@karemuvar I would recommend for you to test two things.
The first would be to use the tablet tester, just go to:
Settings → Configure Krita → Tablet Settings → Open Tablet Tester
The other one would be to disable Canvas Graphics Acceleration, then restart Krita.
This will lower your drawing fps and make operations like pan and rotate slow. However we would be investigating another thing with this.
In both cases we are trying to exclude the GPU leverage over the cursor delay. This would help to confirm that the lag is bound to the GPU and not the processor.
Either way this would be a investigative venture and won’t provide much of any solution, but we would have a more solid direction to tackle this issue.
The important part is that this is a Qt problem, not a Krita problem. Usually this mean a developer would have to halt developing Krita’s main code, and instead fix Qt’s code. Also, this should be done by the Krita community because Qt is currently at version 6, with the version 5.15 LTS still active. However Krita uses a modified, custom made 5.12 version, so any fix by Qt developers would not affect Krita (probably).
Thanks for the reply. What is so interesting is that I can see the latency issue with my regular wacom tablet while drawing in Krita. Normally this is not an easy to catch issue in other apps since most of the time the mouse pointer would be pretty close to where the brush is, however in Krita this distance is noticeable with fastish strokes. This gets even more noticeable when Krita used with a display graphics pen device like Wacom Cintiq Pen, given the user now can compare three different things (vs two points with a regular tablet) , the display pen tip, the mouse pointer and the brush location.
There seems to be a general confusion around when someone talks about brush delay or lag. Most people assume this is a CPU or GPU performance related issue. I see that Ralek totally nails it down. This is a brush latency issue that occurs between the mouse pointer>brush location>pen tip ( or mouse pointer>brush location with a regular graphics tablet)
This kind of latency is greatly improved with the Ipad Pro, the drawing nearly always just below the pen tip, basically the brush is always in sync with where the pen tip is in Ipad Pro+Apple Pencil. I have never seen a Wacom based device ( I used many of them over the years including Samsung Android Note tablets/phones) that can offer similar performance like Apple Pencil when it comes to pen tip tracking with the mouse pointer. However, because there is a hardware latency with these display graphic tablets does not mean that all apps suffer with the issue at the same level. To me this issue is more noticeable in Krita, especially with mid-level speed drawing (like not too slow or not too fast brush strokes)
I was able to improve it slightly with the recommendations above, and I feel like the crosshair cursor seems to offer the best tracking which is interesting
The tracking speed in tablet tester is much snappier compared to the situation in Krita canvas.
Disabling acceleration or other GPU performance methods did not help with the situation much.
Thanks for testing it.
If the Tablet Tester has similar delay to PS than we can infer that the part of Krita responsible for receiving and handling pen input is fine.
Keep in mind that Krita don’t use the GPU to compute any stroke or ‘pen drawing’, it only shows the image it receives from the CPU.
Disabling GPU acceleration don’t make much of a difference, then we can be more confident that the delay is not “only visual”. This means that as far as the program is concerned the brush really is “physically” delayed behind the cursor, and not only appearing being delayed.
Conclusion:
The problem (probably) is not the same as @Ralek, which is more of a stutter / frame pacing issue.
Yours is a physical and real delay of the brush behind the cursor. I’m not familiar with the specifics of Krita code, but my hypothesis are:
Another thing. Maybe is important to distinguish if the brush has a “slow start”, meaning it takes longer to start moving after the cursor started moving, and after this the distance between cursor to brush is constant.
Or if it is overall slower, meaning the brush widen the distance behind the cursor over time (and maybe even ‘jumps’ ahead to catch up with the cursor).
Sorry for the lengthy posts. I personally find really interesting these optimization challenges. I find amusing investigate its causes and possible (yet theoretical) solutions.
If I were more capable I wouldn’t mind trying and contribute to better Krita code on these regards.
Cheers.
The thing is more:
so yes, some people here will tell you they don’t have problem and everything works fine for them.
it doesn’t means Krita don’t have any problem, just that Krita is working fine for them 
also, even if on my side I never complain about brushes engine, I already open miscellaneous bugd reports about performance problem on other functional perimeter of Krita
sorry for disgressing on subject, that was just for precision because people here are not blind Krita purists, they just don’t have the same problems, same feeling or same experience
concerning problem described here, I clearly just can’t help, it’s not in the perimeter of performance problem I already encounter
Grum999
Is it possible for you to record a movie of it? You need to record it with a camera/phone, a desktop screen recording won’t record the issue.
Here is as low as I’ve managed to get it to go, this included switching OS to Linux where the software seems to be better supported and Nvidia’s native frame buffering doesn’t get in the way. Crosshair is cursor location (Pen driver delay), circle is OpenGL delay (Krita native canvas delay), and the pen line is the brush processing delay.
Wacom Cintiq 24 Pro with Pro Pen 2 @ 180hz position polling rate, suppress rate 0 and raw sample rate 1. 60hz screen with OpenGL canvas reporting at 180 fps (This is because Krita’s OpenGL canvas is limited to the polling rate of the pen used)
(Recorded at 240 FPS, playback speed 30FPS, 1/8th realtime)
Thanks, do you feel like the new Wacom Cintiq Pro 27 with 120hz would improve the lag issue?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.