Bug 417040 - No pressure at first stamp in floating dock mode
Summary: No pressure at first stamp in floating dock mode
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tablets (tablet issues are only very rarely bugs in Krita!) (show other bugs)
Version: 4.2.8
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2020-02-01 22:53 UTC by Igor
Modified: 2020-09-04 20:27 UTC (History)
3 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 Igor 2020-02-01 22:53:44 UTC
SUMMARY
I lost pressure sensitivity at first stroke after switching from float docks (I use brush preset, history of brushes, artistic color picker) . It doesn’t happen each time, about 2/3 or 2/4.

Screenshot:
https://krita-artists.org/uploads/default/original/2X/e/e10a7fc50393190be95545ff60c1284afa648105.jpeg 

Video:
https://youtu.be/6X9kABr41Zw

The same effect if I switching from other program e.g. browser or video player back to Krita.

In attached dock mode all OK except switching from other programs.

It happens only in WinTab mode. WinInk doesn't have such bug (but alas have other)

The current “First stump” issue is only Krita “feature” (other painting software is ok).
I and other users tested it with the same result on various systems:
Ryzen 1600 + GTX960
Athlon 200GE + internal GPU
I3 6100 + internal GPU
i3 4030 + internal GPU
i7 9700K + RTX 2070 
Intuos5, Cintiq 13hd + ProPen (KP-503E stylus)
Systems used with Single Display and with Two displays.
Windows 7, 8, 10


It seems concern only senior series of wacom tablets (Intuos 4, 5, Pro, Pro2 and Cintiqs). Wacom Intuos Draw ("Bamboo" types) doesn't have that issue. 


STEPS TO REPRODUCE
0. Need Wacom Intuos (from 4 up to Pro2) or any Cintiq
1. Be sure using WinTab mode
2. Undock (make float) color selector
3. Make a brush stroke, change color
4. Repeat №3 several times

ADDITIONAL INFORMATION
forum discussion link:
https://krita-artists.org/t/no-pressure-at-first-stamp-in-floating-dock-mode/1847
Comment 1 Halla Rempt 2020-02-03 09:24:41 UTC
Could you please make a tablet log, too? I'm afraid that it'll turn out to be a driver problem (because behaviour differs from tablet to tablet) and that we cannot do much, but a tablet log would show whether we get tablet events at all when the main window get focus. See https://docs.krita.org/en/contributors_manual/user_support.html#gathering-information
Comment 2 Halla Rempt 2020-02-03 09:24:54 UTC
Changing status
Comment 3 Igor 2020-02-03 15:59:04 UTC
(In reply to Boudewijn Rempt from comment #1)
> Could you please make a tablet log, too? I'm afraid that it'll turn out to
> be a driver problem (because behaviour differs from tablet to tablet) and
> that we cannot do much, but a tablet log would show whether we get tablet
> events at all when the main window get focus. See
> https://docs.krita.org/en/contributors_manual/user_support.html#gathering-
> information

Log:
https://invent.kde.org/uploads/-/system/user/983/a32e3b1523e13b830a4442380bdc7fbc/tablet_log2

Screenshot with strokes during logging:
https://invent.kde.org/uploads/-/system/user/983/8d55a8e2fa16a9c3d60cb2ffe15fd424/tablet_log2_strokes.jpg
Comment 4 Bug Janitor Service 2020-02-04 04:33:17 UTC
Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.
Comment 5 Halla Rempt 2020-02-17 15:00:35 UTC
I'm sorry, but those links are broken :-(
Comment 6 Igor 2020-02-17 21:28:15 UTC
(In reply to Boudewijn Rempt from comment #5)
> I'm sorry, but those links are broken :-(

Hmm, log is opened without problem, only image has a problem. I reuploaded files to "yandex" https://yadi.sk/d/N0Nvg1auErvLgg
Comment 7 Halla Rempt 2020-04-01 13:52:21 UTC
You don't need to update the version field; the version field indicates the  version of Krita when the the bug was first discovered. Until the bug is fixed, it's assumed that it exists in all subsequent versions, too.
Comment 8 Tiar 2020-08-03 17:46:29 UTC
The relevant part of the tablet log:

##################

"[BLOCKED 2:] MouseMove        btn: 0 btns: 0 pos:  932, 463 gpos: 2852, 546 hires:     2852,     546 Source:0"
"[       ] TabletMove       btn: 0 btns: 0 pos:  928, 462 gpos: 2848, 545 hires:  2847.93, 545.185 prs: 0.000000 Stylus Pen id: 8805681213932 xTilt: 36 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[       ] TabletMove       btn: 0 btns: 0 pos:  928, 462 gpos: 2848, 545 hires:  2848.18, 544.691 prs: 0.000000 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[       ] TabletMove       btn: 0 btns: 0 pos:  928, 461 gpos: 2848, 544 hires:   2848.3, 544.252 prs: 0.000000 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[BLOCKED 2:] MouseMove        btn: 0 btns: 0 pos:  933, 462 gpos: 2853, 545 hires:     2853,     545 Source:0"
"[       ] TabletPress      btn: 1 btns: 1 pos:  928, 461 gpos: 2848, 544 hires:  2848.42, 543.868 prs: 0.147526 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
Accessing uninitialized random source!
"[       ] TabletMove       btn: 0 btns: 1 pos:  928, 461 gpos: 2848, 544 hires:  2848.42, 543.703 prs: 0.147526 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[       ] Enter            "
"[       ] FocusIn          "
Stop blocking mouse events
"[BLOCKED 1:] MouseButtonPress btn: 1 btns: 1 pos:  933, 462 gpos: 2853, 545 hires:     2853,     545 Source:0"
"[       ] MouseMove        btn: 0 btns: 1 pos:  933, 461 gpos: 2853, 544 hires:     2853,     544 Source:0"
"[       ] TabletMove       btn: 0 btns: 1 pos:  928, 461 gpos: 2848, 544 hires:  2848.42, 543.594 prs: 0.174383 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
Start blocking mouse events
"[       ] TabletMove       btn: 0 btns: 1 pos:  928, 460 gpos: 2848, 543 hires:  2848.42, 543.484 prs: 0.179754 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[       ] TabletMove       btn: 0 btns: 1 pos:  929, 460 gpos: 2849, 543 hires:  2848.54, 543.484 prs: 0.188055 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[       ] TabletMove       btn: 0 btns: 1 pos:  929, 460 gpos: 2849, 543 hires:  2848.54, 543.484 prs: 0.197821 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[       ] TabletMove       btn: 0 btns: 1 pos:  929, 460 gpos: 2849, 543 hires:  2848.54, 543.484 prs: 0.239845 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[       ] TabletMove       btn: 0 btns: 1 pos:  929, 461 gpos: 2849, 544 hires:  2848.54, 544.087 prs: 0.255470 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[BLOCKED 2:] MouseMove        btn: 0 btns: 1 pos:  933, 462 gpos: 2853, 545 hires:     2853,     545 Source:0"
"[       ] TabletMove       btn: 0 btns: 1 pos:  929, 462 gpos: 2849, 545 hires:  2848.54, 545.404 prs: 0.269173 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "
"[BLOCKED 2:] MouseMove        btn: 0 btns: 1 pos:  933, 463 gpos: 2853, 546 hires:     2853,     546 Source:0"
"[       ] TabletMove       btn: 0 btns: 1 pos:  928, 465 gpos: 2848, 548 hires:  2848.42, 547.654 prs: 0.287729 Stylus Pen id: 8805681213932 xTilt: 35 yTilt: 11 rot: 0 z: 0 tp: 0 "

##################

Basically when it changes focus out of Krita's window (and a floating docker probably is one), Krita stops blocking mouse events (since in Wintab Krita always gets both of them). The next window is of course also Krita, so Krita doesn't know yet that there is tablet involved: there was no "tablet is getting near the surface" event. So Krita gets both a mouse event and a tablet events. Since the mouse event is first, Krita create a stamp with 100% pressure. Then a tablet event comes and Krita starts blocking mouse events, but it's too late already...

I bet that in the different app -> Krita it works the same way - Krita doesn't block mouse events because it doesn't know yet that there is tablet somewhere.

Since this behaviour is most probably implemented by Qt, I'm not sure if Krita can do anything. I don't know which component is at fault here either.
Comment 9 Dmitry Kazakov 2020-08-24 16:02:43 UTC
Note: wintab only
Comment 10 Dmitry Kazakov 2020-09-04 18:58:45 UTC
Yes, I can reproduce the problem (even with a Huion tablet).
Comment 11 Dmitry Kazakov 2020-09-04 20:26:55 UTC
Git commit 4f98a20fbf2e64858b28ad22ca809d95c40a00be by Dmitry Kazakov.
Committed on 04/09/2020 at 20:16.
Pushed by dkazakov into branch 'krita/4.3'.

Fix full-pressure blobs when using floating dockers

On Windows tablet events may arrive asynchronously to the
mouse events (in WinTab mode). The problem is that Qt
generates Enter/Leave and FocusIn/Out events via mouse
events only. It means that TabletPress may come much before
Enter and FocusIn event and start the stroke. In such a case
we shouldn't unblock mouse events.

PS:
Ideally, we should fix Qt to generate Enter/Leave and
FocusIn/Out events based on tablet events as well, but
it is a lot of work.

M  +0    -5    libs/ui/input/kis_input_manager.cpp
M  +0    -3    libs/ui/input/kis_input_manager.h
M  +21   -0    libs/ui/input/kis_input_manager_p.cpp

https://invent.kde.org/graphics/krita/commit/4f98a20fbf2e64858b28ad22ca809d95c40a00be
Comment 12 Dmitry Kazakov 2020-09-04 20:27:29 UTC
Git commit 081c38c8763c94c79b132aafc99f1b087b88d421 by Dmitry Kazakov.
Committed on 04/09/2020 at 20:27.
Pushed by dkazakov into branch 'master'.

Fix full-pressure blobs when using floating dockers

On Windows tablet events may arrive asynchronously to the
mouse events (in WinTab mode). The problem is that Qt
generates Enter/Leave and FocusIn/Out events via mouse
events only. It means that TabletPress may come much before
Enter and FocusIn event and start the stroke. In such a case
we shouldn't unblock mouse events.

PS:
Ideally, we should fix Qt to generate Enter/Leave and
FocusIn/Out events based on tablet events as well, but
it is a lot of work.

M  +0    -5    libs/ui/input/kis_input_manager.cpp
M  +0    -3    libs/ui/input/kis_input_manager.h
M  +21   -0    libs/ui/input/kis_input_manager_p.cpp

https://invent.kde.org/graphics/krita/commit/081c38c8763c94c79b132aafc99f1b087b88d421