Bug 442544 - Krita 5.0's Shift modifier to change brush size is not behaving as expected.
Summary: Krita 5.0's Shift modifier to change brush size is not behaving as expected.
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Freehand (show other bugs)
Version: 5.0.0-beta2
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Emmet O'Neill
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-16 17:35 UTC by Tyson Tan
Modified: 2021-11-18 08:49 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tyson Tan 2021-09-16 17:35:11 UTC
Krita 5.0's Shift modifier to change brush size is not behaving correctly. It keeps jittering about its size, very hard to control, and feels very buggy. I think the problem lies in a recent change that allows it to Shift + Drag all directions.

Previously in Krita 4.x, we can only Shift + Drag Left/Right to change the brush's size. Now in Krita 5.0, we can Shift + Draw all directions to change the brush's size, with Up/Left being increase, Down/Right being decrease in size. 

The problem is, what happens when we drag towards Up-Left or Down-Right? The app can't make up its mind to whether increase or decrease the brush size, but can only dance back and forth. As both human and the nature of the graphics tablet, when we drag, there is no way we can avoid some movement being registered as an opposite direction on both axis. In the past I can just close my eyes and drag towards left/right in general knowing it will increase/decrease my brush size, but now I have to pay attention to drag diagonally from Down-Left to Up-Right. I can't deviate much from the 45 degree line either, or the brush size will jump around. It makes a very frustrating experience.

Therefore, I wish this change in behavior can be reverted.
Comment 1 tomtomtomreportingin 2021-10-02 20:28:29 UTC
Hey Tyson, it's been a couple weeks since this report: Do you still feel the same way about this issue?

This change may have been born out of a user suggestion, so there might be conflicting opinions on this.
Comment 2 Tyson Tan 2021-10-03 00:06:36 UTC
The experience has improved recently. Now I don't get the same jumping between sizes that I found when I reported the bug. There must be some kind of bug at that time that cause the issue. I think we can close this bug now.
Comment 3 Tyson Tan 2021-11-10 14:51:51 UTC
After a period of intense drawing, I decided to reopen this bug. My opinion in Comment 2 was inaccurate as I wanted to trust the judges from "other users". But in reality, the new method has completely ruined the Shift brush-size-change experience for me. It's so unreliable and keeps jumping between increasing/decreasing size while my cursor moved steadily towards only one direction. 

I would strongly recommend against this change. If you insist to do so, please leave an option to turn it off, and better yet, don't turn it on by default. Otherwise I think the Shift modifier will become something you "can" use, but actually nobody would use.
Comment 4 Tyson Tan 2021-11-10 15:10:10 UTC
My point being, the old method allows consistent size change when the brush moves towards any direction, while the new method basically denies the use of Up-Left or Down-Right movement. But we just can't eliminate Up-Left/Down-Right movement in reality.

It's not difficult to see why this is bad idea -- just press Shift and drag the brushtip towards Up-Left or Down-Right. Can you increase/decrease the brush size without it struggles to go the other way?
Comment 5 tomtomtomreportingin 2021-11-15 15:40:29 UTC
I don't have a personal preference on this myself, but I'm not a dev. I'm not sure if it can necessarily be considered a confirmed bug, but it could be a problem if a user is unable to get used to this change even after a couple months.

For reference, this is the commit that implemented shift-vertical dragging: https://invent.kde.org/graphics/krita/-/commit/4cb4711b0315b01b79d8064865ede596d1205368
Comment 6 Tyson Tan 2021-11-15 18:29:09 UTC
I think if a function for adjusting the brush size (which is supposed to provide precision and consistency) can't provide precision and consistency (which it did before this change), and obvisouly has negatve impact in a productivity appliaction, it should be considered a regression. As a heavy, experiened user of Krita, this change makes the drawing experience very unpleasant. Shift brush size change was the key function that brought me to Krita, it's sad to see it become something that I can't use anymore. If you must take this direction, I'd recommend at least find a way to make it more stable and consistent before pusing it to the front stage, or just give us a switch to turn it off. Please.
Comment 7 Emmet O'Neill 2021-11-15 23:07:01 UTC
Git commit 366e42d4448463b8571560a1c57aa651c6eaee27 by Emmet O'Neill.
Committed on 15/11/2021 at 23:06.
Pushed by emmetoneill into branch 'krita/5.0'.

Revert "Freehand Tool: Shift-Vertical Drag can now be used to resize too."

This reverts commit 4cb4711b0315b01b79d8064865ede596d1205368.

Dexterity considerations.

M  +2    -3    libs/ui/tool/kis_tool_freehand.cc

https://invent.kde.org/graphics/krita/commit/366e42d4448463b8571560a1c57aa651c6eaee27
Comment 8 Emmet O'Neill 2021-11-15 23:09:56 UTC
Git commit 4807d9c8992454e1eb741edc96dc061c9fd42299 by Emmet O'Neill.
Committed on 15/11/2021 at 23:09.
Pushed by emmetoneill into branch 'master'.

Revert "Freehand Tool: Shift-Vertical Drag can now be used to resize too."

This reverts commit 4cb4711b0315b01b79d8064865ede596d1205368.

Dexterity considerations.


(cherry picked from commit 366e42d4448463b8571560a1c57aa651c6eaee27)

M  +2    -3    libs/ui/tool/kis_tool_freehand.cc

https://invent.kde.org/graphics/krita/commit/4807d9c8992454e1eb741edc96dc061c9fd42299
Comment 9 Tyson Tan 2021-11-16 05:23:19 UTC
Thank you Emmet! :)
Comment 10 Emmet O'Neill 2021-11-18 03:11:04 UTC
(In reply to Tyson Tan from comment #9)
> Thank you Emmet! :)

You're welcome Tyson. If this is hurting your ability to illustrate with Krita, then it's certainly safer and smarter to revert it for now.

However, I want to note a few things:

1. The ability to resize the brush by dragging vertically  (as an alternative to the existing horizontal drag) was something that had been user requested. This request seems pretty reasonable, as there's nothing that makes horizontal dragging for brush size any more intuitive or ergonomic than vertical. While reverting this patch is positive from your perspective (and that certainly means a lot considering your long relationship the project), it's important to keep in mind that it will be disappointing to those who requested it.

This can be remedied by making this behavior configurable, but even then people will disagree over what the default behavior should be. 
It's also not something we can do right now, since we're in string freeze for Krita 5.0.

2. From my personal testing and painting recently, I'd argue that the problem is being overstated here. The awkward fighting/jumping between enlarging and reducing brush sizes only occurs in two very specific directions, 4:30 and 10:30 o'clock, for lack of a better description. Of course, this is the natural fulcrum/fault-line where we draw a distinction between enlargement (right/up) and reduction (left/down). 

You'll notice that this issue has always existed with Krita, and continues to exist after this patch has been reverted, it's just that we've shifted the problem angles. If you hold shift and drag directly up or down even after the revert, you'll experience the same annoying clash between brush enlargement and reduction that this bug is describing, and (when you factor out muscle memory) I'd argue that it's in an even more annoying place.

There's the possibility of creating a dead zone or buffer between the enlargement direction and reduction direction, but that would of course mean that nothing at all would happen when dragging perfectly along the fault-line. I'm not sure if that's any better than the clashing situation, but maybe it's worth trying...

3. I think we can agree that intuitive pen gestures like this are an important part of painting workflow. I'd like us to have an open mind in the future and explore other possibilities for improving quick gesture-based controls, because it could lead to a more expressive and fluent interaction for artists. 

Since shift brush size change was the key function that brought you to Krita, then I think it's safe to say that there is a lot of potential value in making this feature better or developing related features--it's just a matter of figuring out ways that we can do it that are net-positive and flexible enough to suit the tastes of various artists, and your input will be a huge help in getting there.

---

Anyway, I'm playing it safe here and reverting because your experience and opinions are important to us! 
I hope you'll consider the points I'm making and let us know what you think can be done to improve and build upon these kinds of gestures.

Thanks as always for the report Tyson,
Emmet
Comment 11 Emmet O'Neill 2021-11-18 03:21:55 UTC
Oh, and one other thing that I just thought of...

In regards to the NW - SE "fault-line" issue that I mentioned above: if you are left handed like me, then a big part of the problem could be that this fault-line coincides with one of the more naturally comfortable brush stroke directions. Random thought, but that's certainly something to consider...
Comment 12 Tyson Tan 2021-11-18 08:49:14 UTC
Thank you Emmet for the detailed explanation. As you mentioned, I agree that my left-handedness might have played a key role here. It's so much more natural for me to move my left hand on NW-SE line. The jumping in size is severe because of that.