Summary: | flicker in slidingpopups: setData(WindowClosedGrabRole) gets lost | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Marco Martin <notmart> |
Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | sebas |
Priority: | NOR | ||
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/kde-workspace/0d9582627e055f80c380a8812aa81ba4b9379fc7 | Version Fixed In: | |
Sentry Crash Report: |
Description
Marco Martin
2014-01-15 11:45:09 UTC
do you have caching enabled in the blur effect and does the issue disappear if you disable it? This patch moves the WindowClosedGrabRole call from windowClosed() to windowAdded(), fixes the bug for me. https://git.reviewboard.kde.org/r/115903/ Git commit 0d9582627e055f80c380a8812aa81ba4b9379fc7 by Sebastian Kügler. Committed on 20/02/2014 at 13:38. Pushed by sebas into branch 'master'. slidingpopups claim windowClosedGrabRole earlier This seems like a more proper fix for the flickering issue in the sliding popups effect. The problem is that slidingpopups grabs the window in windowClosed, the fade effect checks it there, which makes it racy. In my tests, I've not seen this problem with the WindowAddedGrab, but as far as I understand, the problem may well be present there as well. (And my proposed trick doesn't work.) I've not seen this happening in my debugging, however. The problem there is also less visible since the transparency curves go into the same direction, and are more "in line with each other". So, fix: Move the setData(WindowClosedGrabRole, ...) call from windowClosed into windowAdded, which makes sure it's set whenever the window goes away. REVIEW:115903 M +5 -1 kwin/effects/slidingpopups/slidingpopups.cpp http://commits.kde.org/kde-workspace/0d9582627e055f80c380a8812aa81ba4b9379fc7 |