Bug 313795 - with Kwin compositor activated, some stroke events are dropped/missing on qpainter canvas
Summary: with Kwin compositor activated, some stroke events are dropped/missing on qpa...
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: git master (please specify the git hash!)
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
Depends on:
Reported: 2013-01-24 01:07 UTC by David REVOY
Modified: 2013-03-30 18:49 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:

missing strokes screenshot exemple (270.85 KB, image/jpeg)
2013-01-24 01:07 UTC, David REVOY
video of the 'Present Windows' effect on stroke (1.71 MB, video/mp4)
2013-01-24 12:17 UTC, David REVOY
output of 'qdbus org.kde.kwin /KWin supportInformation' (4.93 KB, text/plain)
2013-02-05 10:30 UTC, David REVOY
log file "catched" after the 'present windows' effect (33.26 KB, text/plain)
2013-02-06 19:41 UTC, David REVOY

Note You need to log in before you can comment on or make changes to this bug.
Description David REVOY 2013-01-24 01:07:59 UTC
Created attachment 76675 [details]
missing strokes screenshot exemple

Since last weeks, I had a problem of random "missing strokes" while sketching fast or taking notes,  or while cross-hatching ( so, while doing a lot of stroke event on my tablet very fast ). 
"Missing stroke" are just lines not painted , so I do the gesture on the tablet, but it's like if Krita doesn't understand an action is sent. Cursor moves, but nothing is painted. 

At first, I thought the culpit was my hardware ; thinking my stylus is getting old and not register events. Then, later, I tried with a second spare stylus I have ; and had the same effect.   I also tested in Mypaint , and didn't had this missing stroke. ( It's quite easy to reproduce here as seen on screenshot in attachment. )

Then I tried to deactivate Kwin on my Linux Mint KDE 14 , and it also removed the bug of missing stroke input. Good. But a bit ironic, because I was really happy since a week of Kwin and the fact its the only compositor around on Linux D.E. who doesn't slow down my painting experience... Now I found a reason to desactivate it by default. 

So, I continued to test further and saw also this 
Kwin effect + OpenGL canvas :  no missing lines  

So to resume :
- Kwin effect + Qpainter canvas : missing lines  ( bug )
- Kwin effect + OpenGL canvas :  no missing lines  
- no effect + Qpainter :  no missing lines
- no effect + OpenGl : no missing lines
Comment 1 Halla Rempt 2013-01-24 09:45:33 UTC
Outch... I have to admit that for now, I haven't got any idea what this could be!
Comment 2 David REVOY 2013-01-24 12:14:24 UTC
New informations : 
It seems to be very dependent of my setup ; dual-screen Cintiq + Monitor , Nvidia proprietary driver ,  Kwin Fx.
If I want to reproduce it, I have to abuse of desktop effect prior to that or it won't work on a fresh booted computer. 
Exemple : Use the Effect ' Present Windows' ( I have the shortcut keyboard here Super+A to show all the application open , watch the video in attachement ). 
Right after initiating this effect , all strokes are lost on Krita as the video 'missing-stroke.mp4' show.  Also, the missing strokes are back after abusing this effect. Thats why the effect is probably stronger on my setup 'at the end of the day'.
Comment 3 David REVOY 2013-01-24 12:17:21 UTC
Created attachment 76682 [details]
video of the 'Present Windows' effect on stroke

The video was reduced for the weight to 640x480 mp4  , excuse the quality. The original screen is 1600x1200 . It's the right screen of my dual monitor setup. Captured with Kazaam , downscaled with mencoder.
Comment 4 Halla Rempt 2013-01-24 13:08:52 UTC
I'll ping mgraesslin tomorrow -- this could be either a bug in kwin, or a bug in Qt, or (most probably) a bug in the driver... It's extremely unlikely to be a bug in krita :-)
Comment 5 Christoph Feck 2013-01-30 23:34:19 UTC
Is the KWin team aware of this one? They are quite experts on GL slowdowns ;)
Comment 6 Martin Flöser 2013-02-04 19:54:58 UTC
@David: which version of KWin are you using?
Comment 7 David REVOY 2013-02-05 02:51:27 UTC
@Martin : I use KWin: 4.9.4
Qt: 4.8.3
KDE Development Platform: 4.9.4
Comment 8 Martin Flöser 2013-02-05 06:40:23 UTC
as it's 4.9, please run:
qdbus org.kde.kwin /KWin supportInformation

and post the output.
Comment 9 David REVOY 2013-02-05 10:30:43 UTC
Created attachment 76919 [details]
output of 'qdbus org.kde.kwin /KWin supportInformation'
Comment 10 Martin Flöser 2013-02-05 10:37:59 UTC
as I feared it doesn't show a setting which I could imagine to interfere. So let's try whether it's a general compositing issue by switching to XRender.

Please start from a Konsole:
KWIN_COMPOSE=X kwin --graphicssystem native --replace &

This restarts kwin with XRender. Once it's running again please try to verify whether that problem is still present.

By using kwin --replace & you are switching back to normal OpenGL accelerated KWin.
Comment 11 David REVOY 2013-02-05 17:09:48 UTC
The bug of can't paint after an effect 'Present Windows' is called is here in Xrender and OpenGL but it sound more like a focus stealing thing. 

The missing stroke happen after a long usage, so I can't reproduce right now, and I'll try to keep Xrender in my setup and paint next days to see if I still have missing painting stroke. 

Something maybe not related , while doing the test ( Xrender / OpenGL ) via the terminal line you gave, I had this output on OpenGL ( who differer from the other log message of Xrender ) :
sh: 1: --crashes: not found
KCrash: Application 'kwin' crashing...
Fatal Error: Accessed global static 'KGlobalPrivate *globalData()' after destruction. Defined at ../../kdecore/kernel/kglobal.cpp:127
Unable to start Dr. Konqi

Other output for both :
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated.
kwin(4110) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_blur"  is not supported 
kwin(4110) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_startupfeedback"  is not supported 
kwin(4110) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_cube"  is not supported 
kwin(4110) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect  "kwin4_effect_coverswitch"  is not supported
Comment 12 Thomas Lübking 2013-02-05 17:55:28 UTC
The present window thing sounds related to the effect input window not being hidden or anything else violating the stacking order.
Since you can cause it at will please set a long delay timer in konsole

sleep 30; xwininfo > buggy_window.txt; xprop >> buggy_input_window.txt

(notice that the double arcs >> are correct in that position)

now you've 30 seconds to get into the state where this would happen, the cursor will then twice turn into a cross. Just click where you'd paint each time and attach the resulting buggy_input_window.txt here

Reg. the missing stroke, try runnig "krita --style plastique" and see whether you can cause this here as well (might be related to oxygen dragging, the window is maximized and likely won't react - the option is not in supportinformation)
Comment 13 David REVOY 2013-02-06 19:41:08 UTC
Created attachment 76952 [details]
log file "catched" after the 'present windows' effect

Hey, now I understand better why I had impossibility last days to reproduce the missing stroke. 
In fact it's really linked about the timing to the moment I found this tip : http://www.davidrevoy.com/data/images/blog/2013/01/mint14kde/linux-mint-kde-14-digital-painting_bonus4.jpg and published on my blog. This dragging things was driven me crazy with a stylus to hit button , combobox etc... Nice to know it's a highly probable culprit. 

Since yesterday I have composition running with Xrender, and the overall behave nicely. Thanks for your terminal command line to 'catch' 'Present Windows' problem . I did it , and attached the log file to this comment.
Comment 14 Thomas Lübking 2013-02-06 21:47:26 UTC
Ok, sum up ;-)

a) missing stroke is perhaps (probably, likely, related to) oxygens ability to drag the window from everywhere?!
-> attached Hugo.

b) the attachment does not contain the output of xwininfo (command not installed, not called - or you only used one ">" for the second call ;-) but the window is just krita.
Since you seem to be able to "fix" it by just selecting another brush in krita (w/o leaving the window, deactivating it, altering the general window stack order etc.) the issue most likely is in krita.
Comment 15 Halla Rempt 2013-02-22 15:05:05 UTC
Hm... I'm not sure I know what that remaining issue in krita is likely to be...
Comment 16 Thomas Lübking 2013-02-22 15:39:19 UTC
Watch the video: after activation (through present window) he cannot paint unless he selects another brush.

1. events are delivered to krita (or he couldn't select a brush)
2. krita seems in a wrong assumtion about the current mode which "somehow" gets cleared by the brush selection (like eg. in a very naive scenario, if you related the painting mode on the pointer shape and that got invalidated by the interim actions)
Comment 17 David REVOY 2013-02-22 15:55:09 UTC
I also noticed something maybe related and found probably interesting to continue here  : a lag when using floating docker in Krita ( even with or without Kwin activated ) , mainly with the advanced color selector , because I tested a lot this one . 

The scenario is simple : 
- Use advanced color selector in floating mode
- paint on canvas
the various focus between canvas and the floating dockers make the brush having a lag when hitting the canvas. 

Workaround : I tend to dock everything
Comment 18 Thomas Lübking 2013-02-22 16:02:48 UTC
could be related to animations in the oxygen decoration
Comment 19 Hugo Pereira Da Costa 2013-02-22 16:41:38 UTC
Git commit f464dadc5e2e43a1c30967bd9e99928e81729f23 by Hugo Pereira Da Costa.
Committed on 22/02/2013 at 17:39.
Pushed by hpereiradacosta into branch 'master'.

Fixed disabling/enabling decoration animations in non-advance mode

M  +3    -2    kwin/clients/oxygen/config/oxygenconfigwidget.cpp

Comment 20 Hugo Pereira Da Costa 2013-02-22 16:46:04 UTC
testing comments #14 and #18 is easy.
One can disable the window dragging feature in oxygen style configuration:
system-settings->application appearance->style->(oxygen) configure->window's drag mode (from title bar only)

and disable oxygen's decoration animations in 
system-settings->workspace appearance->window decorations->(oxygen)->configure decoration->enable animations (uncheck)

(just fixed it in "master", and should not be broken in 4.10 and earlier)

... or select a different widget style and/or decoration and see if issues still happen.

Keep me posted.

Comment 21 Halla Rempt 2013-03-30 13:36:45 UTC
Hm... Can we close this bug now?
Comment 22 David REVOY 2013-03-30 18:06:16 UTC
@Boud : Yes , I think its possible to mark this one closed, as it was finally mainly related to Oxygen theme and Qpainter.