[krita] [Bug 339870] Very difficult to increase brush size using Shift + dragging-right when zooming in

[Tyson Tan]

https://bugs.kde.org/show_bug.cgi?id=339870

--- Comment #1 from Tyson Tan <tysontan-***@public.gmane.org> ---
P.S.
On a ***@600dpi document zooming to 100%, use fill_circle brush which has a
default size of 50px, Shift-drag to right. When the brush size has been
increased to around 100~128px, it pretty much stops going larger and starts to
go backward (smaller) if your right-dragging speed slows down.

[Dmitry Kazakov]

https://bugs.kde.org/show_bug.cgi?id=339870

Dmitry Kazakov <dimula73-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |dimula73-***@public.gmane.org

--- Comment #2 from Dmitry Kazakov <dimula73-***@public.gmane.org> ---
Well, there is at least one problem: when the mouse's cursor (which is hidden)
hits the rightmost side of the monitor (or the tablet hits its side) it cannot
move anymore. So obviously one cannot scale the brush further. Which is, yes,
quite inconvenient.

Do you mean this problem or something else?

I also feel that the brush scales a bit slower than the cursor itself, but I
guess it was done somehow intentionally to allow more precise control of the
size. Which exact problem do you mean?

[Tyson Tan]

https://bugs.kde.org/show_bug.cgi?id=339870

--- Comment #3 from Tyson Tan <tysontan-***@public.gmane.org> ---
Hi, Dmitry

when the mouse's cursor hits the rightmost side of the monitor it cannot move anymore

No, this is not what I meant.

it was done somehow intentionally to allow more precise control of the size

I do notice that in Krita 2.8, the brush size changes slower when I zoom in. No
matter how much I zoomed, the increasing speed is constant and smooth.

Meanwhile in Krita 2.9 pre-alpha, however, the decreasing of brush size works
fine, but the increasing does not:

1) When I Shift + drag to towards right when zoom in, the brush size increases
very little, and stops increasing from now and then, EVEN WHEN I WAS STILL
DRAGGING IN A STEADY SPEED. The more I zoom in, the easier it chokes.

2) Sometimes the brush size DECREASES even when I was dragging towards RIGHT.
Especially when I was dragging SLOWLY.

3) When it happened, the cursor was NOT even far away from the CENTER of canvas
(because I'm drawing).

4) When it stops increasing, I can drag faster and move further to make it work
again, but ONLY FOR A BLINK OF TIME. It will stop increasing in the next
second.

I guess as the brush engine got changed a lot recently, it creates some
incompatibility with the old Canvas intereaction, causing this bug.

[s***@public.gmane.org]

https://bugs.kde.org/show_bug.cgi?id=339870

supersayoyin-***@public.gmane.org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |supersayoyin-***@public.gmane.org

--- Comment #4 from supersayoyin-***@public.gmane.org ---
This patch fixes it:
https://git.reviewboard.kde.org/r/120610/

[Dmitry Kazakov]

https://bugs.kde.org/show_bug.cgi?id=339870

Dmitry Kazakov <dimula73-***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Latest Commit| |http://commits.kde.org/call
| |igra/c8c7cb8ecc7b96cbd34cf4
| |60d5994da190addfda
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED

--- Comment #5 from Dmitry Kazakov <dimula73-***@public.gmane.org> ---
Git commit c8c7cb8ecc7b96cbd34cf460d5994da190addfda by Dmitry Kazakov, on
behalf of Gerald Young.
Committed on 17/10/2014 at 14:07.
Pushed by dkazakov into branch 'master'.

Fixes Krita Bug 339870.

The issue was two fold. Firstly on krita/ui/tool/kis_tool_freehand.cc
didn't respond well to slow dragging motions. The brush size can only
increment in integer pixel values, but a slow dragging motion generates
increments smaller than one pixel. These small increments get truncated
once passed to brush settings and the drag motion is discarded. Solution
was to accumulate the drag motion until it is higher than one pixel.

A second problem was that KisDoubleSliderSpinBox would implicitly convert
the provided qreal to an int value. This conversion works like the floor
function, for example turning a 0.1 into a 0 value (ok) and
turning a -0.1 value into a -1 value (not ok). This was the cause of the
weird behavior where brush size would decrease even when dragging right
slowly. Solution was to use qRound to avoid the implicit conversion.
REVIEW:120610

Thanks Gerald Young for the patch! :)

M +5 -3 krita/ui/tool/kis_tool_freehand.cc
M +1 -1 krita/ui/widgets/kis_slider_spin_box.cpp

http://commits.kde.org/calligra/c8c7cb8ecc7b96cbd34cf460d5994da190addfda

[Tyson Tan]

https://bugs.kde.org/show_bug.cgi?id=339870

--- Comment #6 from Tyson Tan <tysontan-***@public.gmane.org> ---
Yes, it's fixed! Thank you Gerald and Dmitry!
:)

[Tyson Tan]

https://bugs.kde.org/show_bug.cgi?id=339870

--- Comment #1 from Tyson Tan <***@mail.com> ---
P.S.
On a ***@600dpi document zooming to 100%, use fill_circle brush which has a
default size of 50px, Shift-drag to right. When the brush size has been
increased to around 100~128px, it pretty much stops going larger and starts to
go backward (smaller) if your right-dragging speed slows down.

[Dmitry Kazakov]

https://bugs.kde.org/show_bug.cgi?id=339870

Dmitry Kazakov <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #2 from Dmitry Kazakov <***@gmail.com> ---
Well, there is at least one problem: when the mouse's cursor (which is hidden)
hits the rightmost side of the monitor (or the tablet hits its side) it cannot
move anymore. So obviously one cannot scale the brush further. Which is, yes,
quite inconvenient.

Do you mean this problem or something else?

I also feel that the brush scales a bit slower than the cursor itself, but I
guess it was done somehow intentionally to allow more precise control of the
size. Which exact problem do you mean?

[Tyson Tan]

https://bugs.kde.org/show_bug.cgi?id=339870

--- Comment #3 from Tyson Tan <***@mail.com> ---
Hi, Dmitry

when the mouse's cursor hits the rightmost side of the monitor it cannot move anymore

No, this is not what I meant.

it was done somehow intentionally to allow more precise control of the size

I do notice that in Krita 2.8, the brush size changes slower when I zoom in. No
matter how much I zoomed, the increasing speed is constant and smooth.

Meanwhile in Krita 2.9 pre-alpha, however, the decreasing of brush size works
fine, but the increasing does not:

1) When I Shift + drag to towards right when zoom in, the brush size increases
very little, and stops increasing from now and then, EVEN WHEN I WAS STILL
DRAGGING IN A STEADY SPEED. The more I zoom in, the easier it chokes.

2) Sometimes the brush size DECREASES even when I was dragging towards RIGHT.
Especially when I was dragging SLOWLY.

3) When it happened, the cursor was NOT even far away from the CENTER of canvas
(because I'm drawing).

4) When it stops increasing, I can drag faster and move further to make it work
again, but ONLY FOR A BLINK OF TIME. It will stop increasing in the next
second.

I guess as the brush engine got changed a lot recently, it creates some
incompatibility with the old Canvas intereaction, causing this bug.

[s***@gmail.com]

https://bugs.kde.org/show_bug.cgi?id=339870

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #4 from ***@gmail.com ---
This patch fixes it:
https://git.reviewboard.kde.org/r/120610/

[Dmitry Kazakov]

https://bugs.kde.org/show_bug.cgi?id=339870

Dmitry Kazakov <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Latest Commit| |http://commits.kde.org/call
| |igra/c8c7cb8ecc7b96cbd34cf4
| |60d5994da190addfda
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED

--- Comment #5 from Dmitry Kazakov <***@gmail.com> ---
Git commit c8c7cb8ecc7b96cbd34cf460d5994da190addfda by Dmitry Kazakov, on
behalf of Gerald Young.
Committed on 17/10/2014 at 14:07.
Pushed by dkazakov into branch 'master'.

Fixes Krita Bug 339870.

The issue was two fold. Firstly on krita/ui/tool/kis_tool_freehand.cc
didn't respond well to slow dragging motions. The brush size can only
increment in integer pixel values, but a slow dragging motion generates
increments smaller than one pixel. These small increments get truncated
once passed to brush settings and the drag motion is discarded. Solution
was to accumulate the drag motion until it is higher than one pixel.

A second problem was that KisDoubleSliderSpinBox would implicitly convert
the provided qreal to an int value. This conversion works like the floor
function, for example turning a 0.1 into a 0 value (ok) and
turning a -0.1 value into a -1 value (not ok). This was the cause of the
weird behavior where brush size would decrease even when dragging right
slowly. Solution was to use qRound to avoid the implicit conversion.
REVIEW:120610

Thanks Gerald Young for the patch! :)

M +5 -3 krita/ui/tool/kis_tool_freehand.cc
M +1 -1 krita/ui/widgets/kis_slider_spin_box.cpp

http://commits.kde.org/calligra/c8c7cb8ecc7b96cbd34cf460d5994da190addfda

[Tyson Tan]

https://bugs.kde.org/show_bug.cgi?id=339870

--- Comment #6 from Tyson Tan <***@mail.com> ---
Yes, it's fixed! Thank you Gerald and Dmitry!
:)