Does anyone use speed control in their brush presets? (A proposal)

I’m close to putting in a formal bug report about the speed control of brush preset properties.

I find that even with very, very fast strokes I can’t get near the Fast end of the transfer curve.

a) Is this only me who has this problem?

b) Does anyone use speed control of brush presets which would be affected by simple rescaling of speed? (Maybe there could be an option selection mod that wouldn’t affect existing presets.)

This is not related to the problems experienced by the author of this topic:
https://krita-artists.org/t/speed-sensor-in-brush-settings-doesnt-seem-to-work-correctly/6037/4

I haven’t used the speed control much but yea the fastest speeds seem impossible to get to for me. But after I adjusted the curve and minimized the spacing it works kinda

Before I put a bug report in, I’d like to show what I mean and make a suggestion to see if anybody has objections to it.

Here is a simple speed → size brush preset:

I used this on a 2048 x 2048 canvas with brush size set to 205px (10% canvas size). It seems that the speed is measured in screen pixels per second so the canvas size has no effect, which is good.
As you can see, I was unable to get to the ‘Fast’ end of the charcateristic even when I swept my stylus over the canvas at ludicrous speed:

Modifying the transfer curve to only use the lower 25% of the speed range:

Then I can do these strokes which are still at ludicrous speed:

With a transfer curve using only the lower 10% of the speed range, I can get these strokes at ‘reasonable’ speed:

I’d propose that speed scaling is altered by a factor of about x 8 to make it immediately more useful and practical.

Further flexibility could be provided by making this an option by means of a checkbox which when not ticked would not alter anything (and so not affect existing presets) but when ticked would set speed to x 4 scaling and also put a slider up with range 1-10 that could be used to further multiply the speed scaling. This would let users adjust it to suit their own idea of what is ‘reasonable’.

Any thoughts?

Just curious: If it’s screen pixels per second does it mean higher res screens (let’s say 4k + same physical size as let’s say FHD) get to the top limit easier or is your example of a 4k screen?

I don’t know about hi-res screens and I may have been wrong to use the expression ‘screen pixels’. Maybe it’s ‘canvas widths per second’ or something like that.
I have a 17" 1280 x 1024 screen so it would be interesting to know if anyone with a modern high res screen has the same opinion.
The difference between reasonable, high and ludicrous is very subjective of course.

I would suggest just adding an option to scale it, like Distance and Time has, so some kind of “Maximum Speed” (speed on the right side of the curve). What do you think? And the speed would have to be in “manageable” units somehow, so, for example, it could be that the original max speed would be 100, and then your new suggestion would be around 12. So the default value would be 100, to not break anyone’s brushes, and then the suggested would be around 12.

1 Like

That would be the simplest and most understandable solution if it could be done.
As you say, the slider would default to 100, the current scaling (or not scaled) factor. Then I’d slide it down to 10 to get what I called ‘reasonable’ speed response. Anyone who wants slow easily controlled hand movements could set it to 5 (or whatever), people who like to do long fast sweeps could set it to 30 or more, etc.

Should I put that in as a wishlist bug now (soon) or wait for more feedback and comment?

Wishlist bug report: https://bugs.kde.org/show_bug.cgi?id=421098