After moving a window, the window's translucency is often not dialed back. This means that moving a window a few times, it becomes fully transparent and thus invisible. This doesn't happen for all windows all the time, but it happens quite regularly. Switching compositing off and on again makes the window visible again. Reproducible: Sometimes
Happens for me as well. Different types of windows - gtk, qt, chromium-whatever-toolkit ... Unfortunately, I was not able to discover a pattern.
As reported on IRC earlier, 76fa302 is definitely good commit in KWIn.
This happened to me this morning on un-suspending my computer and moving windows to the second monitor, Firefox went translucent. I'm on Neon dev unstable (master Plasma branches). I've not been able to recreate it since.
ooh it just happened again! Umbrello (a Qt5/KF5 app) after switching desktops but same monitor.
It happens for me too. But I can't reproduce it, I hit it only twice when moving Chromium by accident (Chromium was maximized).
https://bugs.kde.org/show_bug.cgi?id=342716#c18
I have the same issue, KDE neon DevEd unstable, Plasma 5.7.2 nvidia GeForce GTX 750 Ti/PCIe/SSE2 It happens once after boot. Workaround with "compositing off/on". If I don't correct it this way and move some windows, I sometimes see Bug 342716, like Thomas Lübking already explicated above, but don't find any regularity. It's an exhausting bug.
like Sebastian, I see this and the ghost windowing as well. I hadn't seen this in Neon until almost 3-4 days later, now today after a reboot due to plasma consuming 200% of my cpu cores, the windows staying translucent/dimmed is happening immediately. I posted my support info from kwin in Bug 342716, happy to provide whatever else helps you fix these.
Steps to reproduce: 1. Open an X11 window on desktop 1 2. Send it to desktop 2 through kwinactions menu 3. switch to desktop 2 4. move the window
Possible patch at https://phabricator.kde.org/D2346
Git commit 671740dc70c4d2fb091320c0da564cf2ea6029b2 by Martin Gräßlin. Committed on 03/08/2016 at 14:16. Pushed by graesslin into branch 'master'. Ensure that EffectsHandlerImpl::slotClientShown is only invoked once per Window Summary: This fixes a regression introduced with a1afeded6ae63e47d39fc08480e929c0451c51e8. The connections were setup every the windowShown signal got emitted. This caused effects to get multiple singals and start multiple animations which then do not get cancelled correctly. The incorrect behavior was most visible in the translucency effect which did not cancel the move animation and the window stayed translucent. Test Plan: New test case which simulates the behavior of the translucency effect. Reviewers: #kwin, #plasma, sebas Subscribers: kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D2346 M +1 -0 autotests/integration/CMakeLists.txt A +3 -0 autotests/integration/effects/CMakeLists.txt A +185 -0 autotests/integration/effects/translucency_test.cpp [License: GPL (v2)] M +1 -1 effectloader.h M +1 -0 effects.cpp http://commits.kde.org/kwin/671740dc70c4d2fb091320c0da564cf2ea6029b2
Not sure how related, but I had a weird echo in the dimming module as well as translucency, as I use both to make non-focus apps somewhat ghosted/backgrounded. I've observed when I get the ghosting, clicking between two ghosted windows repeatedly causes them to continually dim further with the translucency and never returning to full focus, thus the "echo" comment. It just keeps dimming until it's unviewable, or I restart compositing. This seems to be present in more modules than just translucency potentially?
Side note too, Martin's example to reproduce does not work for me, not after a fresh reboot last night and minimal activity until today. I switch a lot of windows back and forth, even between desktops, and doing so does not immediately manifest itself after reboots. It's only after some time (~1-2 days) that this starts occurring normally, and sometimes moving just on the same screen triggers it. I just had Okular get peculiar, where I'd minimize and leave an impression of the translucent window stuck in the compositing I couldn't remove, where un-minimizing it, behaved perfectly normal until minimizing again, resulting in "ghost". Such as: 1. Open url to download PDF, default to Okular reader. 2. Navigate document paging through. 3. Minimize document, leaves resulting translucent ghost image on screen, cannot remove/manipulate. 4. Un-Minimize Okular, window reappears in focus, can move window normally. 5. Leave Okular on desktop, work with other applications, come back to read pdf 10 minutes later on screen, minimize works normally again. More odd "coming and going" of these issues with compositing and general destabilization over time.