| Summary: | with Kwin compositor activated, some stroke events are dropped/missing on qpainter canvas | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | David REVOY <info> |
| Component: | General | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | halla, hugo.pereira.da.costa, hugo, kwin-bugs-null |
| Priority: | NOR | ||
| Version: | git master (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
missing strokes screenshot exemple
video of the 'Present Windows' effect on stroke output of 'qdbus org.kde.kwin /KWin supportInformation' log file "catched" after the 'present windows' effect |
||
Outch... I have to admit that for now, I haven't got any idea what this could be! 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'. 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.
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 :-) Is the KWin team aware of this one? They are quite experts on GL slowdowns ;) @David: which version of KWin are you using? @Martin : I use KWin: 4.9.4 Qt: 4.8.3 KDE Development Platform: 4.9.4 as it's 4.9, please run: qdbus org.kde.kwin /KWin supportInformation and post the output. Created attachment 76919 [details]
output of 'qdbus org.kde.kwin /KWin supportInformation'
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. 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 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) 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. 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. Hm... I'm not sure I know what that remaining issue in krita is likely to be... Watch the video: after activation (through present window) he cannot paint unless he selects another brush. Means: 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) 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 could be related to animations in the oxygen decoration 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 http://commits.kde.org/kde-workspace/f464dadc5e2e43a1c30967bd9e99928e81729f23 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. Hugo Hm... Can we close this bug now? @Boud : Yes , I think its possible to mark this one closed, as it was finally mainly related to Oxygen theme and Qpainter. |
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