Bug 306528

Summary: Unwanted blots in the begining of the brush strokes
Product: krita Reporter: yustas <igor-leskov1962>
Component: Brush enginesAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED FIXED    
Severity: minor CC: adaptee, dimula73, halla, igor-leskov1962
Priority: NOR    
Version: 2.5   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In:
Attachments: Opacity dots.
Size dots.
Partial resolving the problem
Additional trick.

Description yustas 2012-09-10 06:25:49 UTC
There is an old annoying problem with the any pen tablets in the any 2D packages. Sometimes when you draw short fast strokes with the light presure with your stylus disgusting blobs occur in the begining of the strokes. I know no one 2D packages or hardware developers who deal with resolving this bad feature with the exepton of ArtWeaver package developer. Artweaver has 'Ignor First Point' option in the general preferences.
Do with it something, please.
Comment 1 Dmitry Kazakov 2012-09-11 19:22:54 UTC
Hi, Yustas!

Thank you for your report! Could you describe the problem a bit more? Is it simply a point in the beginning of the stroke or something more complex? Probably, a screenshot might help us a bit.

Btw, we have an option for configuring the size of the brush in relation to the pressure of the stylus. It can be done with a curve. You can try to set the curve, so that the size of the brush would be 0 for too small pressures. If it solves your problem, we could try to invent a kind of a dead zone for the pressure as well. Can you try that?
Comment 2 yustas 2012-09-12 02:32:51 UTC
Created attachment 73844 [details]
Opacity dots.

It is not of the brush size problem only.
Comment 3 yustas 2012-09-12 02:36:18 UTC
Created attachment 73845 [details]
Size dots.

The curve do nothing with it.
Comment 4 yustas 2012-09-12 02:42:37 UTC
Created attachment 73846 [details]
Partial resolving the problem

Some tricks reduсe the negative effect but do not eliminate it.
Comment 5 yustas 2012-09-12 02:43:48 UTC
Created attachment 73847 [details]
Additional trick.
Comment 6 yustas 2012-09-12 02:58:42 UTC
It is an old and general pen tablet problem. These are some links for the impression of it:

1) http://73.adobe-illustrator-windows.overzone.net/2-questions-1-about-saving-twice-2-aboutlarge-blobs-with-wacom-tablet-t5104.html (ESPECIALLY THE SECOND MESSAGE)

2) http://forum.wacom.eu/viewtopic.php?f=7&t=8408)
Comment 7 Dmitry Kazakov 2012-09-14 11:21:38 UTC
Hm, this is rather interesting problem. According to the forums mentioned here, the windows driver can sometimes send two kind of events to the application: mouse click (pressure = 100%) + mouse down (pressure = real pressure) and the application simultaneously. We'll have to think what can be done with that.
Comment 8 Dmitry Kazakov 2012-09-14 12:46:22 UTC
Ok, I'll try to make a patch for this, although I don't have an ability to reproduce it yet.
Comment 9 Jekyll Wu 2012-09-24 13:22:38 UTC
*** Bug 290400 has been marked as a duplicate of this bug. ***
Comment 10 Dmitry Kazakov 2013-03-18 14:19:56 UTC
Git commit ff05026331c9f3937cb396d908c2f9c7e6aac726 by Dmitry Kazakov.
Committed on 18/03/2013 at 15:19.
Pushed by dkazakov into branch 'master'.

Fixed the input manager on windows

There are two points there:
1) Windows defers the mouse events generated by the ignored tablet events,
   so the former ones arrive reordered.
2) The flow of tablet move events is too high, so there is a special option
   "hiResInputEvents" introduced in the action to handle it. All the actions
   except painting itself use compressed mouse move events instead.

M  +5    -0    krita/ui/input/kis_abstract_input_action.cpp
M  +9    -0    krita/ui/input/kis_abstract_input_action.h
M  +42   -7    krita/ui/input/kis_input_manager.cpp
M  +28   -0    krita/ui/input/kis_shortcut_matcher.cpp
M  +12   -0    krita/ui/input/kis_shortcut_matcher.h
M  +6    -0    krita/ui/input/kis_tool_invocation_action.cpp
M  +2    -0    krita/ui/input/kis_tool_invocation_action.h
M  +32   -1    krita/ui/tests/kis_input_manager_test.cpp

http://commits.kde.org/calligra/ff05026331c9f3937cb396d908c2f9c7e6aac726
Comment 11 Dmitry Kazakov 2013-03-18 17:41:40 UTC
Git commit 639be738bb71579e91bbfe0a3a759af7cf712b20 by Dmitry Kazakov.
Committed on 18/03/2013 at 15:19.
Pushed by dkazakov into branch 'calligra/2.6'.

Fixed the input manager on windows

There are two points there:
1) Windows defers the mouse events generated by the ignored tablet events,
   so the former ones arrive reordered.
2) The flow of tablet move events is too high, so there is a special option
   "hiResInputEvents" introduced in the action to handle it. All the actions
   except painting itself use compressed mouse move events instead.

M  +5    -0    krita/ui/input/kis_abstract_input_action.cpp
M  +9    -0    krita/ui/input/kis_abstract_input_action.h
M  +42   -7    krita/ui/input/kis_input_manager.cpp
M  +28   -0    krita/ui/input/kis_shortcut_matcher.cpp
M  +12   -0    krita/ui/input/kis_shortcut_matcher.h
M  +6    -0    krita/ui/input/kis_tool_invocation_action.cpp
M  +2    -0    krita/ui/input/kis_tool_invocation_action.h
M  +32   -1    krita/ui/tests/kis_input_manager_test.cpp

http://commits.kde.org/calligra/639be738bb71579e91bbfe0a3a759af7cf712b20
Comment 12 yustas 2013-03-25 01:58:59 UTC
It sounds impressive. Thanks a lot Dmitry.