Why do some brushes perform S.U.P.E.R. slow in Krita? It gets pretty annoying pretty fast, does Krita not have code for multithreading? Or is this another problem maybe?

Is it a top priority issue to fix? (It should be since it is severely limiting, sometimes it is so severe it will sometimes make the program hang for a matter of minutes; Which completely kicks me out of my workflow, it's not 3D rendering, it's simple 2D lines! Yet it becomes about as slow as a basic scene rendering in 3D modeling programs like blender)

A very easy way to reproduce this is to fire up krita and set up a canvas (I personally use a 5K widescreen 16:9 canvas, or 1920x1080*3) pick the hairy squared brush, bump it up to maximum size and then just draw a simple straight line. See how many minutes it takes to finish. This sluggishness becomes noticable after just resizing the brush a little bit, but then it starts multiplying until the canvas is about as snappy and responsive as a snail, koala or sloth.

This is currently my biggest issue with the program and occurs on both windows and linux (and no, it is not my system, I have 24GB of Ram and a 3.4-3.8ghz quad core i7 with two graphics cards (since I like to play with blender). If your program is slow with this, it can be nothing else than poor code optimization)

Do you know about the brush precision setting? It was created for just these types of situations where you are painting with very large brushes. You can lower the quality of the brush interpolation to increase the brush responsiveness. For how large your brush is, setting it to 1 should help somewhat. There is actually an "auto" mode that will change the quality based off the brush size. Not sure if that helps.

Krita does use multithreading and SSE/AVX. Different brushes use different settings and steps to paint. Not all the steps can be parallized or use SIMD. The most optimized brush is Pixel brush with the default setting. Other brushes can't be optimized that well e.g. the hairy brush draw lots of individual smaller lines.

Especially when you are zoomed out with a large brush and you are moving fast there is a considerable amount of computation required. Performance is important but we have to see what the most used features are and concentrate on that.

For the past work see:
http://lukast.mediablog.sk/log/?p=173
http://slangkamp.wordpress.com/2010/10/ ... rocessing/

Sadly the precision setting isn't available for all brushes, it is not available for the brush I mentioned in my example.

slangkamp wrote:Other brushes can't be optimized that well e.g. the hairy brush draw lots of individual smaller lines.

If you are a programmer you should feel very ashamed for having said that.

Other programs have found ways to ensure good performance for all of their brushes, I don't see any problems in photoshop when I use hairy or otherwise funky brushes. This is a problem that no user optimization can fix, but programmers can fix it, it's their job to fix it and I wonder why at such a late time in the release cycle it hasn't been fixed yet.

Sure it's not easy to fix, I can't even imagine. But it needs to be, this is essentially as bad as a game that is so poorly optimized it will lag no matter what computer it is being run on (Basically like X Rebirth). This should really be priority #1, it is broken core functionality, and no amount of excuses can make up for it. Your program will never qualify as anything more than beta until this is fixed, this is not the only thing that needs to be fixed for Krita to be qualified as a top grade artist program, but it is undoubtedly the most important one.

slangkamp wrote:Performance is important but we have to see what the most used features are and concentrate on that.

What feature in Krita do you think is more used than the Brush tool? Isn't that the centerpiece of your program to begin with if it is, shouldn't it always be your top priority to ensure that it lives up to expectation? Should you really be adding to functionality of a feature like the brush tool when it is broken at it's core? shouldn't a stable foundation be first priority instead of last? There's a very thick line between working and being usable, and Krita's brush tool is on the wrong side of it (that is it works, but it is not usable enough)

The possibility that one stroke can take minutes (not an exaggeration here, MINUTES not seconds) to complete depending on the brush type and size is more than just a little bit bad performance. It is the level of breakage that should only be existent in programs at their alpha stage, and I'm sure you know this well.

cestarian wrote:Sadly the precision setting isn't available for all brushes, it is not available for the brush I mentioned in my example.

slangkamp wrote:Other brushes can't be optimized that well e.g. the hairy brush draw lots of individual smaller lines.

If you are a programmer you should feel very ashamed for having said that.

Other programs have found ways to ensure good performance for all of their brushes, I don't see any problems in photoshop when I use hairy or otherwise funky brushes. This is a problem that no user optimization can fix, but programmers can fix it, it's their job to fix it and I wonder why at such a late time in the release cycle it hasn't been fixed yet.

Sure it's not easy to fix, I can't even imagine. But it needs to be, this is essentially as bad as a game that is so poorly optimized it will lag no matter what computer it is being run on (Basically like X Rebirth). This should really be priority #1, it is broken core functionality, and no amount of excuses can make up for it. Your program will never qualify as anything more than beta until this is fixed, this is not the only thing that needs to be fixed for Krita to be qualified as a top grade artist program, but it is undoubtedly the most important one.

These other program have several times more fulltime developers to optimize every little detail different functionality and other limitations. The bristle brush in Photoshop is also different than the one in Krita. So basically what you would have to do is change the behavior of the brush instead of just the code.

I have no idea what optimization tricks Photoshop does to get it's performance. I guess lots of people who spend decades in the field came up with lots of very smart stuff to do it.

Maybe you are more clever than we are and can come up with a better way than we did. It not my "job" to fix it, I'm just doing it in my freetime and not getting paid to do it.

cestarian wrote:

slangkamp wrote:Performance is important but we have to see what the most used features are and concentrate on that.

What feature in Krita do you think is more used than the Brush tool? Isn't that the centerpiece of your program to begin with if it is, shouldn't it always be your top priority to ensure that it lives up to expectation? Should you really be adding to functionality of a feature like the brush tool when it is broken at it's core? shouldn't a stable foundation be first priority instead of last? There's a very thick line between working and being usable, and Krita's brush tool is on the wrong side of it (that is it works, but it is not usable enough)

The possibility that one stroke can take minutes (not an exaggeration here, MINUTES not seconds) to complete depending on the brush type and size is more than just a little bit bad performance. It is the level of breakage that should only be existent in programs at their alpha stage, and I'm sure you know this well.

The pixel brush is actually fairly optimized. The only think that comes to mind is level of detail or mipmapping where a smaller brush stroke is painted while the full stroke is calculated in the background, which is something that is in development right now. If you think you know how it can be done faster, I would be the first person to have a look on it.

There are several brush engines in Krita. Pixel brush is the default one which is the biggest and most important one while e.g. hairy is much less important. Which means that more energy into optimizing that instead of the hairy one. "Make the common case fast" is a general design principal. The thing with the hairy brush is that with growing size more and more bristles are calculated. You might question if Krita should stop you or pull through, but we usually assume that the users knows what he is doing. It's a bit like a car that can drive 250 km/h, it's not saved but you can still do it.

Hi everyone,

Sven wrote:
> These other program have several times more fulltime developers to optimize every little detail different functionality and other limitations. The bristle brush in Photoshop is also different than the one in Krita.

I think all discussion about the Krita brush speed improvement is summed up in this sentence by Sven

As a personal note, I am always surprised about the progress of Krita compared to the very *small* team of developers who work on it

If you think about Photoshop, this software has got more than 20 years of development (by plenty of *full-time* developers and testers)...
Not to mention that it doesn't work on Linux. Therefore, the Adobe programmers have only Windows and Mac to work with
The same period of development goes for Autocad and many other commercial softwares on the market...

At work, I run LibreOffice (instead of Microsoft Office) and even this open source software has many feateurs which are not on par with its proprietary contender (the GUI is much more optimised on Office IMHO).
LibreOffice has many full-time developers working on it (paid by Red-Hat, Collabora, Canonical etc) but there are always many users complaining about the lack of development - features (e.g. Base, the database application of LibreOffice, is completetely neglected by the LibreOffice programmers...).

To get an outstanding software you need many developers who work full-time on it and many years of development (because when you code a new BIG feature you are likely to break something else on the code and you need a lot of time to get everything fixed...).

As regards the Krita brush speed improvements, I have watched a video by Dmitry Kazakov (dimula73) on YouTube which is really promising:
https://www.youtube.com/watch?v=EaFZhrrrPdo

FYI - the hairy brush *does* have the precision setting. It does look like there is a bug though that it isn't showing correctly. At the bottom of the brush editor, there is an "auto" button that you can press. If you press that, it "fixes" the precision setting from hiding itself.

In that video dmitry is using the pixel brush engine, (presumably basic circle) that is pretty impressive actually, but that's still just the pixel brush engine which even in it's current state on 2.8.5 will not be slow enough to actually hang the program when doing that same thing. If pixel brush has been optimized to that extent, it's probably time to move on to the other engines.

I am not finding any auto button in the brush editor... not even for the pixel brushes, are you sure it's available in stable/downstream? I'm on 2.8.5.

slangkamp wrote:Maybe you are more clever than we are and can come up with a better way than we did. It not my "job" to fix it, I'm just doing it in my freetime and not getting paid to do it.

I am pretty clever when it comes to solving problems like this actually, but I am neither a seasoned programmer nor have I ever dabbled in neither graphical nor multithreading code, and as such.. Nothing I can do, if I could I would have already fixed this. If you official krita developers are not getting paid, then what the hell was this for? that's enough money for a single person to live for at least two years!
Are you saying all that money went to KDE development instead of Krita development? Are you saying that money wasn't used to pay people? Then why was it even needed? Didn't the video say it was for funding you and Dmitry?

Being a small team is just another excuse, I mean don't get me wrong, it is amazing how far Krita has come with this few developers, truly. Why are you using that as an excuse? Why would you portray that as a weakness rather than a strength? In-team communication should be less of a problem when someone changes huge chunks of code for you than for a huge company like Adobe or like Corel. There are benefits to being a small team.

The simple fact here is that one of these days whether you like it or not, bugs need to be fixed, and the longer you procrastinate fixing bugs and add more features instead, the more bugs crop up! It's like vegetables, you gotta eat them. It won't be long till people will be using this program on 4K monitors and want to work on 8K resolutions, keeping the hairy brushes this small is not going to be an option at that time (and this is literally just around the corner, give it till about 2016 or 2017)

The pixel brush is reasonably optimized, sure, the other brushes are not. It's ok to not know immediately how to fix it, managing to fix it since it is hard and scary will only make you a better programmer for the effort. You learn the most by doing the things you fear. No amount of excuse justifies an issue of this scale.

But with the brush engine specifically it might not be that hard to troubleshoot; is it the graphical/opengl code that's causing the lag? or is it the brush engine itself? If the latter that indicates that the engine is so inefficient that it's pretty much alpha state, if it's the former then we have a disaster on our hands. But I think it's the engine rather than opengl code in this case, thankfully. So look at how the engine does the calculations. Does it calculate every individual strand? It doesn't need to do that, most strands in most common hairy brushes are parallel. It just needs to calculate one, calculate the spacing between it and the outer brushes, and then copy/paste instead of actually creating each individual strand. Only strands that aren't identical in shape need to be calculated separately.

You're right that the pixel brush is the most important feature, but you're wrong if you think it's the most interesting or unique one.

You have marked the hairy brush, filter brush and hatching brush as stable. I don't know about the filter (nor duplicate brush) but the hatching brushes and hairy brushes are anything but stable.

The spray brush seems to be more optimized than any of these really. So is the grid brush. The experiment brush is pretty far off mark... And the chalk brush is worse off than the hairy one.

But the hairy and pixel brush engines are both very important, anyone can get an efficient pixel brush engine from anywhere, mypaint and gimp are two options, but an efficient hairy brush engine? That's a bit of a rarer sight which would set you a bit more apart.

Don't just settle with being less good than proprietary software. Strive to surpass it instead. Just because they get paid more for their work doesn't make them better programmers, if they are fueled by money and you by passion, who do you think has more motivation to pump out high quality code?

In my opinion, Krita has a featureset that exceeds all other free digital art oriented software, and is mostly on par with professional software like Photoshop and Corel in feature completeness, I mean all the most important things are here, kinda (ok your vectors are a disaster, but that's being worked on, right?), right now, I think lack of optimization is bothering more of Krita's users than lack of features ever will.

Hello Cestarian,

> If you official krita developers are not getting paid, then what the hell was this for [1]?

I am not one of the Krita developers nor I am involved in the Krita development.
As far as I can understand the Krita Kickstarter was meant to improve some specific features specifically selected by artists and users.
These features were 24 in total (of which only 12 were completely sponsored by the users).
This being said, luckilly for us, as soon as Krita 2.9 is released, much more features will be available [2].

> The simple fact here is that one of these days whether you like it or not, bugs need to be fixed, and the longer you procrastinate fixing bugs and add more features instead, the more bugs crop up!

I totally agree with you
Unfortunately, the more features you add on Krita, the more bugs you are forced to fix on it (and this again translates to have a biggest team of developers to do this task...).
Usually, most users are much more interested in having a new feature (instead of pressing the developers to fix bugs).
At present, Krita works on Linux and Windows (and there is even a first basic *alpha* version for Mac as well). Therefore, you are forced to fix bugs on three different platforms right now...
Since, next year, Krita (named version 3) is supposed to be ported on the Qt 5 toolkit I am not even sure it does much sense to concentrate most efforts into the current stable version (2.8.X). By doing so, you would even add more problems because you would end up by having too many versions to deal with (version 2.8, 2.9, 3) ...
From what I have read the 2.9 version should be only an intermediate temporary step until Krita is ported to the Qt 5 toolkit (this last effort should take at least 3 months of full-time work, again based on what I have read...).

In 2008, I have read an interview, on an Italian Linux magazine, where Sven Neumann, one of the lead programmers of Gimp at that time, explained that Gimp was about to being ported to Gegl (the new software back-end to handle all important stuff). Now, around six years later, Gimp is still in the process of doing this passage (and Sven Neumann has stopped working on Gimp since many years now...).

My point is quite simple: IMHO, if you wish to run a very powerful and stable software you do need many full-time developers who work on it and you have to pay them to do so (just think at the Blender Foundation for instance, which has many full-time developers right now thanks to the users donations...).
At present, to my very limited knowledge, there is only Dmitry Kazakov working on Krita full-time

P.s: Adobe, as regards Photoshop, does not even release its software on Linux because there is no market on it to sell its product on this platform [3]

My BEST regards!

[1] https://www.kickstarter.com/projects/kr ... erate-deve
[2] https://www.kickstarter.com/projects/kr ... sts/939022
[3] https://forums.adobe.com/thread/487814?start=0&tstart=0

cestarian wrote:In that video dmitry is using the pixel brush engine, (presumably basic circle) that is pretty impressive actually, but that's still just the pixel brush engine which even in it's current state on 2.8.5 will not be slow enough to actually hang the program when doing that same thing. If pixel brush has been optimized to that extent, it's probably time to move on to the other engines.

I am not finding any auto button in the brush editor... not even for the pixel brushes, are you sure it's available in stable/downstream? I'm on 2.8.5.

slangkamp wrote:Maybe you are more clever than we are and can come up with a better way than we did. It not my "job" to fix it, I'm just doing it in my freetime and not getting paid to do it.

I am pretty clever when it comes to solving problems like this actually, but I am neither a seasoned programmer nor have I ever dabbled in neither graphical nor multithreading code, and as such.. Nothing I can do, if I could I would have already fixed this. If you official krita developers are not getting paid, then what the hell was this for? that's enough money for a single person to live for at least two years!
Are you saying all that money went to KDE development instead of Krita development? Are you saying that money wasn't used to pay people? Then why was it even needed? Didn't the video say it was for funding you and Dmitry?

I would only get money if the 35k € stretch goal was reach, since we got 19955 € I get nothing and all the remaining money goes to pay Dmitry. It's definitely not enough money to pay a single developer for two years at least in Germany (That would be even below the poverty line here). Even the currently money is well below what the industry pays.

All the money goes into Krita. There is a list of tasks that we put together that where the most requested ones and these where voted on by the backers.

cestarian wrote:Being a small team is just another excuse, I mean don't get me wrong, it is amazing how far Krita has come with this few developers, truly. Why are you using that as an excuse? Why would you portray that as a weakness rather than a strength? In-team communication should be less of a problem when someone changes huge chunks of code for you than for a huge company like Adobe or like Corel. There are benefits to being a small team.

It's like they are just having a big team for the sake of it. They have a lot of people and they are all working fulltime. We are outnumbered by Adobe by at least 50 to 1, likely even worse. So unless they are burning 95% of their time in meetings, they would still have more manpower than we have by a huge margin.

cestarian wrote:The simple fact here is that one of these days whether you like it or not, bugs need to be fixed, and the longer you procrastinate fixing bugs and add more features instead, the more bugs crop up! It's like vegetables, you gotta eat them. It won't be long till people will be using this program on 4K monitors and want to work on 8K resolutions, keeping the hairy brushes this small is not going to be an option at that time (and this is literally just around the corner, give it till about 2016 or 2017)

The pixel brush is reasonably optimized, sure, the other brushes are not. It's ok to not know immediately how to fix it, managing to fix it since it is hard and scary will only make you a better programmer for the effort. You learn the most by doing the things you fear. No amount of excuse justifies an issue of this scale.

Which means nothing should stop you from learning how to code . Don't fear it.

cestarian wrote:But with the brush engine specifically it might not be that hard to troubleshoot; is it the graphical/opengl code that's causing the lag? or is it the brush engine itself? If the latter that indicates that the engine is so inefficient that it's pretty much alpha state, if it's the former then we have a disaster on our hands. But I think it's the engine rather than opengl code in this case, thankfully. So look at how the engine does the calculations. Does it calculate every individual strand? It doesn't need to do that, most strands in most common hairy brushes are parallel. It just needs to calculate one, calculate the spacing between it and the outer brushes, and then copy/paste instead of actually creating each individual strand. Only strands that aren't identical in shape need to be calculated separately.

It has nothing to do with OpenGL. The it draws individual bristles each with it's own ink depletion, color and opacity. If you increase the brush size to maximum without decreasing the bristle density it will simulate hundres or thousands of them. There is certainly huge potential to improve, but there is also a number of different areas that are also requested by users as you can see in the other threads here.

cestarian wrote:You're right that the pixel brush is the most important feature, but you're wrong if you think it's the most interesting or unique one.

You have marked the hairy brush, filter brush and hatching brush as stable. I don't know about the filter (nor duplicate brush) but the hatching brushes and hairy brushes are anything but stable.

Acutally it's filed under experimental. In the brush settings on the left there are two labels on the left with "Stable" and "Experimental", at least in 2.8. That got removed after users simply ignored the experimental label.

cestarian wrote:The spray brush seems to be more optimized than any of these really. So is the grid brush. The experiment brush is pretty far off mark... And the chalk brush is worse off than the hairy one.

But the hairy and pixel brush engines are both very important, anyone can get an efficient pixel brush engine from anywhere, mypaint and gimp are two options, but an efficient hairy brush engine? That's a bit of a rarer sight which would set you a bit more apart.

Don't just settle with being less good than proprietary software. Strive to surpass it instead. Just because they get paid more for their work doesn't make them better programmers, if they are fueled by money and you by passion, who do you think has more motivation to pump out high quality code?

In my opinion, Krita has a featureset that exceeds all other free digital art oriented software, and is mostly on par with professional software like Photoshop and Corel in feature completeness, I mean all the most important things are here, kinda (ok your vectors are a disaster, but that's being worked on, right?), right now, I think lack of optimization is bothering more of Krita's users than lack of features ever will.

We wil get there, but it needs time still.

The sooner you get to it the better

As for your remark on learning programming I said I am not a seasoned programmer, not that I wasn't a programmer, I just have very basic programming knowledge, but I can get by (the most remarkable thing I have done was that for 1 week of work, I managed to make the g15daemon driver work with my specific keyboard (G510), the drivers were written in C, I only had experience in C# and Python at the time. But I crawled through it. If I had actually known what I was doing, understood the language and had proper documentation, this would have been 1 day instead.)

But learning harder types of programming, you're not wrong, but I currently have my hands full with learning to paint and Krita has been a real champ in getting me started in a way that no other program (including photoshop and corel painter) could do. On my favorite operating system, Linux

Maybe a few years down the line I'll contribute some code to Krita for my own benefit as a painter, since I fully intend to keep using it until the end of days or another free open source program surpasses it in quality. I don't see this happening in the foreseeable future either.

I don't want to use photoshop because even if I can get access to it (and painter too) I wouldn't want to pay top dollar just so I could use them legally and professionally, which is what ties me to Krita as it is the best program out there for this job that doesn't cost tons of many and isn't restricted to windows or mac (both of which I have a strong distaste for!) if I don't like where I'm at now, I'll have to just feed money to already huge corporations to go elsewhere, and eat microsoft's **** while at it. This is just not gonna happen, so I'm staying with Krita.

Which is why performance matters so much to me. Good optimization is an indication of quality, featureset is an indication of quantity, I think that we have enough quantity for now we just need the quality to get back in line as soon as possible before more work is put into increasing quantity again. (This does not only apply to brush engine optimizations, also layer movement and transformation optimizations)

I don't have brush performance issues on linux only on windows. I've tried this on four different machines. Don't know if it's a compiler issue.

I just compiled the latest version from git, and I am noticing a good amount of improvement in the brush performance, I don't know if the arch official repository binary version is just badly compiled or if this was actually thanks to updates but either way, it's much more usable now. This might however not be the git version and might be because I am now using openbox rather than Enlightenment (I switched to openbox in fact because enlightenment was crashing because of krita and krita was crashing because of enlightenment and I cannot live without Krita)