I’m not sure how complicated this can be on the code level but the idea is simple :
The size changing amount becomes smaller as the brush size becomes smaller.
Need for this is that it becomes harder to adjust the brush size precisely in small sizes.
I remember suggesting (general) minimum brush width feature in the past for the sake of this but I think now that this way would be better.
Good idea but perhaps it would even be better to slow down the speed with an additional modifier key, kinda like Blender does it. That way you can even make it work when making the brush bigger (or any size). As soon as you approach your desired size, you press a key so it makes it easier to fine tune the size in smaller steps.
In theory that sounds shiny but I think if we take it that far it’s a bit too much and I’m not sure there’s a huge need for that in actual usage. As far as I’ve seen the other artists and in my experience it doesn’t need to be constantly microadjusted for 0.1, 0.2 amounts in small sizes…
I second this!
I think just defining the brush change as a percentage would be enough. So if, eg. dragging 1 px would be a 5% change, the change would then be relative to the brush size.
The exact values would need to be tested of course, and also whether or not tuning it to be comfortable at the smaller end of the range results in problems at the high end. I recall that at some point Photoshop changed the brush size slider into some kind of logarithmic version, and it made precise size changes very hard at the higher end of the range. OTOH, that was a pretty small slider and I don’t know what their response curve was, exactly.
I took a little time to look at this, figuring the size logic has to be pretty simple - meaning something I could actually try to change. And it is! In libs/ui/tool/kis_tool_freehand.cc we have:
qreal newSize = m_lastPaintOpSize + sizeDiff
There’s a bit more around it, but basically this means that the relation between distance dragged and diameter change in pixels is constant.
I tried this instead:
qreal newSize = m_lastPaintOpSize * ( 1 + sizeDiff * 0.01 )
So we’re using the drag distance as a multiplier on the brush size now. 0.01 was a scaling factor I arrived at to keep it from being too crazy.
I think this is perhaps nicer than the constant diameter change, but it is quite aggressive at the larger end. I’ve got to do other stuff now, but I think weighting the scaling factor by the brushes initial size somehow to get the change in % to be smaller for larger brush sizes would fix it, just have to figure out how to best do it. Ideas?
I’m not a programmer, just a script juggler, but if you’re already affecting it at this point for the small brushes via the multiplier of your equation, how about varying the multiplier depending on size? So that it defines one (or more) thresholds at which the multiplier is increased or decreased.
Michelist
I think I like what I get with
qreal newSize = 0;
if(sizeDiff < 0){
newSize = m_lastPaintOpSize * (1 + sqrt(qAbs(sizeDiff*10))/-10);
}
if(sizeDiff > 0){
newSize = m_lastPaintOpSize * (1 + sqrt(qAbs(sizeDiff*10))/10);
So basically using square root of the size difference, and an ugly hack to account for sqrt not doing what we need it to do here with negative numbers.
@tiar Maybe you can help here, is there some protocol for providing a build to test? I can build this obviously but I’ve never distributed a build to anyone and wouldn’t like to break anything.
It’s very easy with an appimage (a few comments and then just wait until you get the file 
): Building krita with Docker on Linux — Krita Manual 4.4.0 documentation . With Windows and MacOS, you first need to build it and then I guess use some script from the “packaging” folder? I have only done it with appimages, tbh. (You can pack an appimage without a docker too, I guess also with some script from the packaging folder).
Finally getting around to building this - I noticed there’s maybe an issue with the documentation you linked to. Where it says:
~/bin/run_cmake.sh ~/persistent/krita
For me it needed to be
run_cmake.sh ~/persistent/krita
I’m not sure if dkazakov’s code has changed a bit or if something else is wrong, but there was no run_cmake.sh under ~/bin/ in the docker container once I followed the instructions.