Hi all,

I'm very new and just learning to use krita from scratch. I'm having some issues with my brush speed settings; namely that the inherent sensitivity to speed within the krita brush settings does not match the range of speed that I actually give as input.

More specifically, I want to change the brush size as a function of speed, but the available "curve" space seems to expect a possible range of speed MUCH higher than i can actually produce. Because of this, if I want to actually have noticable change in width with varying speeds, I have to use a VERY steep curve over a very small range of the plot and thus have almost no ability to fine tune the dependance. Please see the picture below with an example of the size/speed dependence curve and resulting behavior for varying speed of strokes (ranging from very fast to very slow):



In contrast, if i leave the default curve (1:1 correlation), the result is virtually zero sensitivity to speed as aparently even my fastest speeds are interpreted as slow. Again, see the example below. Here I start with very slow single strokes at the top, and make the strokes progressively faster until the bottom strokes are as fast as I can swipe on my touch screen (or with my mouse).



As it stands, I can't really control my size/speed relation in any more than a very coarse way. I would ideally like the current behavior shown in the extreme steep case to be the behavior that happens when the curve is a 1:1 straight line. This way I could customize from there with fine control.

My conclusion is that somehow the speed sensitivity within Krita is calibrated badly for my input. Is this a setting I can change? Can anyone give me other advice or information about how to improve the situation?

Thanks and advance and I look forward to hearing from you!

Yeah, this is a known bug, and it's one that keeps kinda... trailing behind unfortunately.

I tried fixing it myself(by lowering the maximum speed, which is 30px a millisecond, which was possible in the old tablet-support system, but not the new one), but the next problem that becomes obvious is that the speed output is extremely uneven... (looks all blobby), and that's kindaq where I got stuck(couldn't make it reliably unblobby).

From what I understand the speed sensitivity is multiplied by the actual brush size to get the final brush size. So if you increment the brush size a lot (in "Brush Tip"), then smaller speed increments should have a more significant effect (even with 1:1 curve).

I had this issue when trying to create a brush with variable spacing based on speed (ie. faster = more spaced). Similarly I couldn't get the spacing to vary much no matter how fast I moved the brush, but by increasing the base spacing in "Brush Tip" I could get more of an effect.

There is really no fix for this? That's very surprising and gives me a big lack of confidence in krita.

This is like the first basic setting I've tried to play with in krita and there is a known failure in functionality that has no fix? I had the impression that kirta was better than that...

I tried playing with brush size a little bit, but I'm not really able to discern a usable relation in brush size and speed that I could exploit to get the behavior I want.

Anyone else have anything to chip in on this issue? This seems like such a basic functionality to need for anyone without pressure sensitive input like me. I can't believe it doesn't work well (at all).

Three different developers have looked at this bug already, and we couldn't get a proper fix.

I could give it another go this week, but don't expect too much. (I really want it fixed myself as well, so motivation isn't the issue.)

In the meantime, the bristle-brush has a mouse-pressure option, which maps size to speed, so you can have fake-pressure there

Edit: I don't think you're the type to build yourself, but I do have a messy patch that works great on small(below 25px) sizes, I would be willing to offer your that, but it isn't a proper fix and doesn't belong in master.(Because commiting it would make the code more difficult to figure out for someone who would be trying to figure out how to properly fix it)

EDIT 2: Kaoron has a working proper patch in review board: https://git.reviewboard.kde.org/r/120875/ It needs fine-tuning, but it's looking good.

Actually I don't think the patches I sent are a proper solution, rather a workaround.

The first version seem to benefit from a happy polynomial accident and feels ok with a slightly adjusted curve, the second one is much more simple and benefits from a log scale but the smoothing feels draggy on deceleration. I still need to get the math right for this.

Moreover, there's really something weird with the raw input and I haven't investigated it yet.