texture paint viewport performance drop #35057

New Issue

Daniel Grauer · 2013-04-23T11:31:13+02:00

Daniel Grauer commented

2013-04-23 11:31:13 +02:00

%%%--- Operating System, Graphics card ---
OS: windows 7 64bit
GPU: nvidia quadro 2000

- Blender version with error, and version that worked ---

error: official 2.66a, r56234

- Short description of error ---

while painting the viewport performance drops to about 5-10 fps which makes drawing nearly impossible

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

open the blend file
make sure you have either a external software to monitor viewport fps like fraps or run animation with playback fps enabled
enter texture paint mode
start painting and notice how the fps drops (especially with smaller brushes)

see the comparison in the attached picture, the fps drops from 80fps to about 5fps.
this issue was also reproduced with the test scene on a linux system.

%%%

%%%--- Operating System, Graphics card --- OS: windows 7 64bit GPU: nvidia quadro 2000 - Blender version with error, and version that worked --- error: official 2.66a, r56234 - Short description of error --- while painting the viewport performance drops to about 5-10 fps which makes drawing nearly impossible - Steps for others to reproduce the error (preferably based on attached .blend file) --- 1. open the blend file 2. make sure you have either a external software to monitor viewport fps like fraps or run animation with playback fps enabled 3. enter texture paint mode 4. start painting and notice how the fps drops (especially with smaller brushes) see the comparison in the attached picture, the fps drops from 80fps to about 5fps. this issue was also reproduced with the test scene on a linux system. %%%

Daniel Grauer commented

2013-04-23 11:31:13 +02:00

Changed status to: 'Open'

Stanislav Blinov commented

2013-04-23 11:38:54 +02:00

%%%Aforementioned linux system is a:
Intel i3 2100
NVIDIA GTS 450 (304.88 driver)
Ubuntu 12.10 amd64

2.66a, 2.66.6 r56160%%%

%%%Aforementioned linux system is a: Intel i3 2100 NVIDIA GTS 450 (304.88 driver) Ubuntu 12.10 amd64 2.66a, 2.66.6 r56160%%%

Antonis Ryakiotakis commented

2013-04-23 16:39:30 +02:00

%%%I can't seem to be able to reproduce on my system.%%%

Antonis Ryakiotakis commented

2013-04-23 17:22:49 +02:00

%%%I was able to reproduce on linux. There is a catch here: older blender versions do space stroking based on radius while newer blender versions do it based on diameter (this happened due to unification of stroke system). that means that we generate double the number of strokes for older versions.

So, if this file was saved with a recent version, to see the real difference between 2.66a and 2.67 you need to double the spacing in 2.66a. An older file opened in 2.67 will have its spacing halved automatically for that reason to match the old behaviour. I expect that there will be some difference due to all the extra stuff that we added but not this much of course. Can you try it with double spacing on older versions? I will also add a warning in our release notes on that.%%%

%%%I was able to reproduce on linux. There is a catch here: older blender versions do space stroking based on radius while newer blender versions do it based on diameter (this happened due to unification of stroke system). that means that we generate double the number of strokes for older versions. So, if this file was saved with a recent version, to see the real difference between 2.66a and 2.67 you need to double the spacing in 2.66a. An older file opened in 2.67 will have its spacing halved automatically for that reason to match the old behaviour. I expect that there will be some difference due to all the extra stuff that we added but not this much of course. Can you try it with double spacing on older versions? I will also add a warning in our release notes on that.%%%

Brecht Van Lommel commented

2013-05-01 17:48:26 +02:00

%%%Any updates here? Since the issue is also reported to be in 2.66a I guess it's not because of the spacing alone. Maybe some GPU specific issue with slow updating of the textures.

Stanislav, are you saying you also see the problem on that system, or did you reply to the wrong report? I'm a bit confused by the use of "aforementioned" here, maybe you mentioned it on IRC or some other channel?

In any case, I can't redo the issue, I can paint quite comfortably at 60 fps in this file with a NVidia 650M on Mac and Linux.%%%

%%%Any updates here? Since the issue is also reported to be in 2.66a I guess it's not because of the spacing alone. Maybe some GPU specific issue with slow updating of the textures. Stanislav, are you saying you also see the problem on that system, or did you reply to the wrong report? I'm a bit confused by the use of "aforementioned" here, maybe you mentioned it on IRC or some other channel? In any case, I can't redo the issue, I can paint quite comfortably at 60 fps in this file with a NVidia 650M on Mac and Linux.%%%

Daniel Grauer commented

2013-05-04 00:20:14 +02:00

%%%he said in IRC that he had the same slowdown with ubuntu. i also tested some older versions today (also back to 2.49b) and it seems this is a really old issue that persisted through all of the updates:/ would be great if this issue could be fixed.%%%

Stanislav Blinov commented

2013-05-05 03:00:44 +02:00

%%%Sorry for the delay. Yes, the "aforementioned" was about the linux system Dan mentioned in his initial report. And yes, doubling the spacing does not seem to resolve the issue on my machine. Fast broad strokes really slowing down, the smaller the brush - the worse. This is already on r56462.%%%

Stanislav Blinov commented

2013-05-05 15:04:20 +02:00

%%%I've upgraded my Ubuntu to 13.04 and NVIDIA driver to 310.44, the slowdown is still present. When I start a stroke I am able to make several quick swipes, then painting slows down to a crawl until I either wait without releasing the pen (I'll be able to continue the stroke once Blender catches up), or just release the pen, wait for Blender to calculate previous stroke and then start anew.%%%

Sanc Tuary commented

2013-05-07 17:35:08 +02:00

%%%Maybe related, i'm on window XP 32 bits, using a G41 Intel "card"

Blender Texture paint mode has always been usable, not very fast tough.
At some point i started to paint bump maps, and there i noticed it was a lot slower, i reported the problem there :
http://projects.blender.org/tracker/index.php?func=detail&aid=33198&group_id=9&atid=498

Then after reading about people reporting the regular texture paint mode being slow, despite for me it's not that slow (while not that fast) i experimented and ran into something i really didn't expected.

In File -> User Preferences -> System, i usually use the Window Draw Method set to "Overlap", i found it to be the optimal setting for the interface when modelling (in the past i had some flickering in popups with other settings)

So i decided to give a try to Triple Buffer , that i usually avoid as i have read some people crashing with it.

I then noticed no difference in the texture paint mode, it's not slow but it's not fast.

Then i enabled the "Region Overlap" setting (that i never use as i don't use Triple Buffer as i mentionned), then went back to paint and .... wow.
Saying that it's fast and smooth is a very small understatement, in fact the texture paint mode is so fast and smooth now that it looks like if my system suddenly upgraded into some nasa quantum computer and sometime replaced my G41 by some Titan without telling me.

I tested a few time to see if i was not hallucinating and indeed i can repeat it everytime, if on my system i use -any- window draw type setting, Blender texture paint mode is usable, not fast but not slow.
But if while i use "Triple Buffer" - and - enable "Region Overlap", it's fantastically smooth and fast, something the kind of smooth and fast i -never- experienced before in Blender, and i use Blender since 2.4

I went back to the bump painting i mentionned in my bug report and same thing , with triple buffer + region overlap, it's lightning fast and smooth to use.

So whatever code is in Region Overlap, it gives on my system a gigantic boost to speed in Texture Paint mode, a more than noticable speed difference in comparison to every other window draw mode i ever used in Blender.
%%%

%%%Maybe related, i'm on window XP 32 bits, using a G41 Intel "card" Blender Texture paint mode has always been usable, not very fast tough. At some point i started to paint bump maps, and there i noticed it was a lot slower, i reported the problem there : http://projects.blender.org/tracker/index.php?func=detail&aid=33198&group_id=9&atid=498 Then after reading about people reporting the regular texture paint mode being slow, despite for me it's not that slow (while not that fast) i experimented and ran into something i really didn't expected. In File -> User Preferences -> System, i usually use the Window Draw Method set to "Overlap", i found it to be the optimal setting for the interface when modelling (in the past i had some flickering in popups with other settings) So i decided to give a try to Triple Buffer , that i usually avoid as i have read some people crashing with it. I then noticed no difference in the texture paint mode, it's not slow but it's not fast. Then i enabled the "Region Overlap" setting (that i never use as i don't use Triple Buffer as i mentionned), then went back to paint and .... wow. Saying that it's fast and smooth is a very small understatement, in fact the texture paint mode is so fast and smooth now that it looks like if my system suddenly upgraded into some nasa quantum computer and sometime replaced my G41 by some Titan without telling me. I tested a few time to see if i was not hallucinating and indeed i can repeat it everytime, if on my system i use -any- window draw type setting, Blender texture paint mode is usable, not fast but not slow. But if while i use "Triple Buffer" - and - enable "Region Overlap", it's fantastically smooth and fast, something the kind of smooth and fast i -never- experienced before in Blender, and i use Blender since 2.4 I went back to the bump painting i mentionned in my bug report and same thing , with triple buffer + region overlap, it's lightning fast and smooth to use. So whatever code is in Region Overlap, it gives on my system a gigantic boost to speed in Texture Paint mode, a more than noticable speed difference in comparison to every other window draw mode i ever used in Blender. %%%

Daniel Grauer commented

2013-05-08 09:30:37 +02:00

%%%i tested the "Region Overlap" option and i dont notice a difference, but what makes a huge difference is the "Window Draw method" i usually have full enabled because all other modes have caused problems with normal map baking, and when i change it to anything else than full i get a huge fps boost.

so with Draw method:
"Full" --> the single digit fps that i reported
anything else --> tripple digits never seen it drop below 100fps so far (with a AMD 7950)%%%

%%%i tested the "Region Overlap" option and i dont notice a difference, but what makes a huge difference is the "Window Draw method" i usually have full enabled because all other modes have caused problems with normal map baking, and when i change it to anything else than full i get a huge fps boost. so with Draw method: "Full" --> the single digit fps that i reported anything else --> tripple digits never seen it drop below 100fps so far (with a AMD 7950)%%%

Marcus Richter commented

2013-05-09 14:39:53 +02:00

%%%I have this problem as well: http:*www.youtube.com/watch?v=kLx_YiaHjI8 (http:*www.blenderartists.org/forum/showthread.php?291323-Texture-Paint-incredibly-slow)

I have an AMD FX-8350 @ 4.0Ghz, 16 Gb RAM, 660 TI 3Gb overclocked, win8 64 bit
system-info.txt: http://www.pasteall.org/42031/text
System Properties: http://pasteall.org/pic/50840%%%

%%%I have this problem as well: http:*www.youtube.com/watch?v=kLx_YiaHjI8 (http:*www.blenderartists.org/forum/showthread.php?291323-Texture-Paint-incredibly-slow) I have an AMD FX-8350 @ 4.0Ghz, 16 Gb RAM, 660 TI 3Gb overclocked, win8 64 bit system-info.txt: http://www.pasteall.org/42031/text System Properties: http://pasteall.org/pic/50840%%%

Brecht Van Lommel commented

2013-05-10 13:57:44 +02:00

%%%I don't know how enabling region overlap can increase performance. I don't see that here, must be some particle graphics driver thing.

The best performing draw method is triple buffer. If it works then it's highly suggested to use that. Full is slow and only should be use if nothing else works.

Marcus, you've got a bunch of options enabled in the system user preferences. Try disabling anisotropic filtering, multisample or region overlap and open the .blend file again. Or do File > Load Factory Settings (this is only temporary), and then load the .blend file to see if any other options are influencing things.%%%

%%%I don't know how enabling region overlap can increase performance. I don't see that here, must be some particle graphics driver thing. The best performing draw method is triple buffer. If it works then it's highly suggested to use that. Full is slow and only should be use if nothing else works. Marcus, you've got a bunch of options enabled in the system user preferences. Try disabling anisotropic filtering, multisample or region overlap and open the .blend file again. Or do File > Load Factory Settings (this is only temporary), and then load the .blend file to see if any other options are influencing things.%%%

Sanc Tuary commented

2013-05-12 14:41:14 +02:00

%%%Yes, i still find it very odd that enabling Region Overlap while being on Triple Buffer mode gives such a boost on my computer, but as i'm using a G41 from Intel, maybe it "accidentally" fixes a problem with whatever Intel drivers has with how region and 3D view recalculations works in Blender.

The only sure thing i see is that it is really making Texture Paint mode working on my system much faster and smoother than it has ever worked, as if i am going to Triple Buffer only it does not boost anything, it's only when enabling that Region Overlap (while in Triple Buffer mode of course).

I wish i knew someone else using a G41 to see if he could confirm this oddity.%%%

%%%Yes, i still find it very odd that enabling Region Overlap while being on Triple Buffer mode gives such a boost on my computer, but as i'm using a G41 from Intel, maybe it "accidentally" fixes a problem with whatever Intel drivers has with how region and 3D view recalculations works in Blender. The only sure thing i see is that it is really making Texture Paint mode working on my system much faster and smoother than it has ever worked, as if i am going to Triple Buffer only it does not boost anything, it's only when enabling that Region Overlap (while in Triple Buffer mode of course). I wish i knew someone else using a G41 to see if he could confirm this oddity.%%%

Daniel Grauer commented

2013-05-13 11:30:46 +02:00

%%%i tested again on the NVIDIA setup again with a new GPU (quadro K4000) and the slowdown is severe, switching to "Triple Buffer" only helps with slow strokes, as soon as i paint a bit faster (and that is by no means fast) the performance drops again and its impossible to paint.
%%%

%%%i tested again on the NVIDIA setup again with a new GPU (quadro K4000) and the slowdown is severe, switching to "Triple Buffer" only helps with slow strokes, as soon as i paint a bit faster (and that is by no means fast) the performance drops again and its impossible to paint. %%%

Daniel Grauer commented

2013-05-13 13:30:24 +02:00

%%%i noticed an other strange behavior, it only seems to happen when i make long strokes, if i make short left - right strokes i can paint super fast without getting a slowdown. any idea why this could happen?%%%

Marcus Richter commented

2013-05-13 23:33:26 +02:00

%%%Brecht, I've tried factory settings on the newest BuilderBot build (r56693) and I still have these problems. Also I have updated my 660TI to use the lastest beta drivers -- doesn't solve the problem either.
The problems occurs both when painting using cycles and BI.
I have no performance issues when using the Image Editor's paint tools%%%

%%%Brecht, I've tried factory settings on the newest BuilderBot build (r56693) and I still have these problems. Also I have updated my 660TI to use the lastest beta drivers -- doesn't solve the problem either. The problems occurs both when painting using cycles and BI. I have no performance issues when using the Image Editor's paint tools%%%

Brecht Van Lommel commented

2013-05-13 23:49:24 +02:00

%%%Dan, long strokes would be expected to be slower just because it takes more processing to paint more pixels. Not sure if it's unreasonably slower. If it's OpenGL drawing that's the bottleneck then longer strokes wouldn't make much difference, if it's the projection painting itself then it would.

Marcus, so you tried with Load Factory Settings, then painting, and it's still slow? Also attaching an example .blend file may help, just in case there is some specific way things are set up.%%%

%%%Dan, long strokes would be expected to be slower just because it takes more processing to paint more pixels. Not sure if it's unreasonably slower. If it's OpenGL drawing that's the bottleneck then longer strokes wouldn't make much difference, if it's the projection painting itself then it would. Marcus, so you tried with Load Factory Settings, then painting, and it's still slow? Also attaching an example .blend file may help, just in case there is some specific way things are set up.%%%

Marcus Richter commented

2013-05-14 01:41:06 +02:00

%%%Brecht, with factory settings I am just drawing on the default cube unwrapped automatically and assigned a 1024x1024 texture, single sided enabled/disabled, all default settings using the most basic methods.%%%

Brecht Van Lommel commented

2013-05-15 16:53:35 +02:00

%%%I fixed some possible performance issues, builds with revision 56823 or newer here will have the fix:
http://builder.blender.org/download/

I doubt it fixes all the problems mentioned here though, probably there are a few different ones here. There's also another possible slowdown due to overhead of creating/destroying threads, will check how to solve that next.%%%

%%%I fixed some possible performance issues, builds with revision 56823 or newer here will have the fix: http://builder.blender.org/download/ I doubt it fixes all the problems mentioned here though, probably there are a few different ones here. There's also another possible slowdown due to overhead of creating/destroying threads, will check how to solve that next.%%%

Daniel Grauer commented

2013-05-16 08:57:42 +02:00

%%%thanks for the effort, unfortunately this does not solve the problem.%%%

Antonis Ryakiotakis commented

2013-06-26 10:05:16 +02:00

%%%Reminder: Another user has also reported this, here

http://www.blenderartists.org/forum/showthread.php?297257-GSOC-2013-MOARZ-texpaint-stuffs&p=2409148&viewfull=1#post2409148

this bug is still there.%%%

%%%Reminder: Another user has also reported this, here http://www.blenderartists.org/forum/showthread.php?297257-GSOC-2013-MOARZ-texpaint-stuffs&p=2409148&viewfull=1#post2409148 this bug is still there.%%%

Brent Lio commented

2013-06-27 08:08:24 +02:00

%%%Hi, I recently updated my blender to 2.67, and now I updated to the newest build, but I'm experiencing some seriously slow performance during texture painting on some bump map details. I used to just turn off project paint to increase performance but now I can't turn it off anymore.

However if I increase the spacing and the brush size, things will go smooth, but the result then is far away from what I wanted. Is it possible to bring back the option to turn off the project paint?

I read some threads in blenderartist forum but nothing is really useful right now.

I'm using a GTX660Ti and i7-3770K, Photoshop sometimes also lags me out but that was when the brush is too big...

Please if this can't be solved easily, add back that option to turn off project paint would help a lot!%%%

%%%Hi, I recently updated my blender to 2.67, and now I updated to the newest build, but I'm experiencing some seriously slow performance during texture painting on some bump map details. I used to just turn off project paint to increase performance but now I can't turn it off anymore. However if I increase the spacing and the brush size, things will go smooth, but the result then is far away from what I wanted. Is it possible to bring back the option to turn off the project paint? I read some threads in blenderartist forum but nothing is really useful right now. I'm using a GTX660Ti and i7-3770K, Photoshop sometimes also lags me out but that was when the brush is too big... Please if this can't be solved easily, add back that option to turn off project paint would help a lot!%%%

Daniel Grauer commented

2013-07-08 11:04:49 +02:00

%%%my coworker notices a significant slowdown after about 10-15minutes so maybe theres some kind of memory leak as well?%%%

Antonis Ryakiotakis commented

2013-07-08 11:40:41 +02:00

%%%I think I have found a lead to fixing this bug. Looks like it's thread related. Setting the threads to 1 in the performance tab reclaims the performance back on my windows system (I'll check elsewhere as well). It looks like there is either some thread conflict here that prevents the system from being fast or some part of the code runs too many times.%%%

Brecht Van Lommel commented

2013-07-08 13:37:30 +02:00

%%%As I mentioned above, starting/stopping threads for each paint dab is really inefficient, especially if the brush size is small. Using something like OpenMP or the task scheduler I made that's in Sergey's depsgraph branch would be more efficient. A quick workaround would be to just avoid threading if the brush is small.

If you want optimal threading usage even for small brushes it requires bigger changes, you'd need to do something like storing multiple brush positions in an array and handle such an array per pixel, otherwise there's too much synchronization overhead. But making small brushes better parallelized probably isn't so important, mostly need to avoid the unnecessary overhead.%%%

%%%As I mentioned above, starting/stopping threads for each paint dab is really inefficient, especially if the brush size is small. Using something like OpenMP or the task scheduler I made that's in Sergey's depsgraph branch would be more efficient. A quick workaround would be to just avoid threading if the brush is small. If you want optimal threading usage even for small brushes it requires bigger changes, you'd need to do something like storing multiple brush positions in an array and handle such an array per pixel, otherwise there's too much synchronization overhead. But making small brushes better parallelized probably isn't so important, mostly need to avoid the unnecessary overhead.%%%

Daniel Grauer commented

2013-07-08 14:27:15 +02:00

%%%we work most of the time with small brushes for small details so for us this is a big deal:(
what can we do to avoid this issue? where can we change this threading thing?%%%

%%%we work most of the time with small brushes for small details so for us this is a big deal:( what can we do to avoid this issue? where can we change this threading thing?%%%

Brecht Van Lommel commented

2013-07-08 14:42:27 +02:00

%%%In the Performance panel you can set threads to Manual and set the value to 1 to disable threading.%%%

Antonis Ryakiotakis commented

2013-07-08 17:37:14 +02:00

%%%I committed Brecht's recommended hack on 58079. I'll leave a better implementation for when we have better task scheduling available. %%%

Antonis Ryakiotakis commented

2013-08-01 19:32:52 +02:00

%%%Could you test if it's working better for you after 58805? I see a great performance increase here for space strokes.%%%

Antonis Ryakiotakis commented

2013-12-17 22:20:32 +01:00

Closing since this is so old and reporter has not replied yet. Better threading will need extensive changes yet and better be done after merging the GSOC branch.

Antonis Ryakiotakis commented

2013-12-17 22:20:55 +01:00

Changed status from 'Open' to: 'Archived'

Antonis Ryakiotakis closed this issue

2013-12-17 22:20:55 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

texture paint viewport performance drop #35057