I also noticed, that if the brush size is much smaller, then the issue disappears, or even with larger brush the lag is not so bad. the worst lag is with medium size brush..

I'm not seeing any poor performance, please attach a .blend file so we're sure to be testing the same setup?

It might also be a threading issue, try changing Render > Performance > Threads to 1 or other values to see if it makes a difference.

Projection painting code is very different than our 2D painting code, the bottleneck here may not be in the 3D viewport, so not necessarily an issue for @Clément Foucault (fclem).

For me it happens with any blend file (just tested again with latest builds). I have also tested it on few different PCs (one pc with amd ryzen 1700 CPU/GTX 1080Ti and another with amd ryzen 2700x/GTX 1080Ti)
Blender 2.79 has also the same issue for me.
Sorry, but I could not find (Render > Performance > Threads to 1) option.

@Sarunas Atkocaitis (Sarunas) you have to switch to cycles for that option to be visible.

Here is a simple test file:

@Brecht Van Lommel (brecht) ah, I see. I guess I was too hasty with the assign then. How should we assign this to (if any)?
If I set the threads to 1, the issue becomes even more apparent. If I try to draw in a circle, the 2D painting code is able to keep up quite well, but the 3D viewport seems to struggle quite a bit.
Do you know if we handle the poll rate of the mouse differently in the 2D viewport than in the 3D viewport?

@Sebastian Parborg (zeddb)
Thanks for adivice.
I have switched threads to 1 and it actually fixed the issue it draws without the lag, but if I put anything else then 1 to the thread count it starts lagging again.

@Sarunas Atkocaitis (Sarunas) interesting, I guess it might just be that I have a really crappy CPU (AMD bulldozer) that I get other results. (Or could also be different under Linux than in Windows)

I can confirm as well that setting rendering threads to 1 resolves the issue but setting rendering threads to anything above 1 causes problems.

I can't find the thread option and I'm having performance problems in the viewport when trying to paint, to the point it's difficult to even make a line.
I have no problem when painting on the Image editor, it behaves smoothly.

Win10 64b
Geforce GTX 1060 3GB
blender-2.80-18e5540a48b6-win64

The Thread option will only be visible if you're using Cycles as your renderer. So switch your rendering engine and you'll be able to reduce your threads. After that, you can switch back to Eevee and it should work fine.

Hi, I used 1 thread in the performance options and the stroke is a lot smoother but still persist a little lag, also this happens in sculpt mode. I used a subdivided cube for the test (No Dyntopo) and this is the result

Cannot reproduce this issue on macOS, even on a low specced laptop. What resolution is your texture?

I have tested in a very new PC with Windows 10:

Intel i9 16 threads
32 GB Ram
RTX2080 TI

I get lag painting textures in a simple cube, and I think the PC is able to run a very heavy work, so it looks there are some bottleneck.

@Brecht Van Lommel (brecht) I could run a Visual Studio performace profiler session to find where is the time used.

Hi, I can confirm that the performance improves a lot by setting the threads to 1.

Here the result in VS2017. I hope this help you.

This seems to be a duplicate of T51133: Bad performance with texture painting depending on multi-thread settings?

@Jeroen Bakker (jbakker) Yes, it's duplicated...you can merge it.

a few tips to better the performance
Set Threads to 1
turn off (Disable) modifiers while painting, (If you need them back just turn them on and try to set their values as low as possible while painting, but again turning them off or disabling gives you the best, )
If its still laggy, try paiting click by click, hold the mouse for a sec while clicked once, if you move the mouse the brush will keep painting even while lagging, and thats why sometimes it lags even more than you expected

I am still getting this issue with Blender 2.81a. Texture painting lags when using large-radius brushes or when painting onto large textures (> 2048). I tried setting Threads to 1 but that made no difference for me.

My issue is a bit different from the original. Performance is worse when painting in the Image Editor instead of the 3D viewport. I wouldn't mind the lag if it didn't also interfere with the input, but it's causing what should be perfectly curved lines to look like they're instead made up of smaller straight lines.

This also happens in linux, tested with ubuntu 18.

However, with small brushes increasing the threads does improve the performance, also, the default brush stroke in 2.81a is "Space", a very "laggy" brush compared with the "Dots" stroke for the new users.

This problem still happens in blender 2.82, and 2.90 alpha, i'm trying looking for a solution but i can't find anything,

This problem seems to be continuing in 2.90 alpha. In my case changing threads, brush size, or any of the other advice did not work. Lag started a few hours ago and has gotten progressively worse with each stroke to the point where Blender is not responsive for several seconds each time I make a stroke in the viewport. Memory usage is not abnormal, and I can still paint in the image editor without problem.

For me, the lag happens when painting over areas where there is backwards-facing geometry under it (trying to paint fingers are a great pathological case), and worsens depending on how many surfaces (backwards or forwards) are stacked under the mouse pointer area. Blender will stop responding to the point where Windows will gray out the screen and consider the app non-responsive.

I did some informal testing:

1. It happens on a similarly-spec'd Ubuntu 18.04 LTS machine, so this is not a Windows-specific issue.

2. Blender appears CPU bound when waiting; I locked the affinity to one core and then watched it peg the core at 100% for almost a minute waiting to respond--about the same amount of time it takes when allowing it to have multiple cores. When affinity is loosened and Blender is not responding, Blender uses ~30% CPU on my 8-virtual-core machine without pegging a particular core.

3. Thread adjustments did not help.

4. RAM usage is normal

What info can I track down to help? Is there a way to see what hotspots Blender is stuck on when it's in this state via debugger or profiler?

Tested versions: 2.82, 2.83 LTS

Tested machines:
Xeon E3 1276 V3
32GB RAM
nVidia GTX 1070
Windows 10

i7-3770k
24GB RAM
nVidia GTX 1070
Ubuntu 18.04 LTS

HI,

It's laggy in 2.83 it's worse in 2.90 thread adjustments did not help.

intel xeon w3690
Nvidia GTX 1080

Here's my proposal on how to improve the performance as well as brush behavior, which was already bad before 2.9. https://blender.community/c/rightclickselect/hncbbc/ Basically, it's about having the option for the brush falloff to be just a sphere instead of a projected 2d tube, in line with the other brushes. The projected tube paints all accros, and this forces the user to use Occlude, which is what kills the performance.

Hello,
I also had the same problem, my brush was lagging in texture paint, both in EEVEE and Cycles.
Though I fond a solution that works for me which is to use orthographic mode only.
Modifying the number of threads for render didn't work for me.

I'm running Blender on a Windows 7 64 bits PC, with an Intel core i5, 16go RAM, NVIDIA GeForce GTX 970

Hello team, I had the same issue with Blender 2.93 (Linux Manjaro, Ryzen 9, 16 gb ram, rtx 2060)
I got the texture painting working by changing the stroke from Space to Airbrush under Brush settings->Stroke->Stroke Method.
Rate .01
JItter 0 (Select the JItter pressure option if you have a tablet)
JItter unit to Brush.

Hope this can fix the issues of some of you.

Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1060 3GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.79
Blender: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash: `rBf1cca3055776`

Still getting very bad performance in 3.0.0 specifically when doing either very big radius strokes or moderately fast strokes. Render Properties>Performance>Threads>1 didn't change anything