> On Feb. 18, 2014, 6:37 a.m., Martin Gräßlin wrote: > > I'm sorry, but you are fixing symptoms and not the problem. Calling the > > repaint is correct, otherwise we might end with artefacts. The problem must > > be that another effect is still holding a reference to the window and thus > > it's being shown again. Try disabling the fade effect or any other closing > > animation effect you might be using. > > Thomas Lübking wrote: > Depending on the flicker it could also be cached blurring (bug #307112) > Otherwise in the long run https://git.reviewboard.kde.org/r/111622/ and > turning this into an AnimationEffect might be a viable path. > (Keeping the transformation as long as the window is kept around would be > the proper solution here as well - "proper syncing" etc. imo does not work in > th light of randomly scripted effects) > > Marco Martin wrote: > when i did some experiments with it back at the sprint, i did see that > the fade effect didn't notice that the window is already managed, > effect.isGrabbed(w, Effect.WindowClosedGrabRole) returns false > see https://bugs.kde.org/show_bug.cgi?id=329991 > > Thomas Lübking wrote: > Or not yet set - first comes, first serves. KWin::ScriptedEffect might be > just up in the effect list. > You could try occupying WindowClosedGrabRole in > SlidingPopupsEffect::slotWindowAdded() but i frankly doubt that this > exclusion concept works in a "bring your own effect" scenario in general at > all (What if two effects think they're responsible for handling it?) > > Either effects operate multiplicative or we'll need a "char > wannaHandle(EffectWindow, QEvent)" pass returning eg. 'm'aybe 'n'o or > 'd'esperately so that the actual event emit will tell the effect whether some > other effect desperately wants the windowevent (and so maybe effects can stay > away) - what does still not solve the case of two desperates, so > multiplicative operation is mandatory again.
yeah, since it happens only some times (if it doesn't do it, it doesn't do it for the whole session, if it does it it does it for the whole sesison) so it depends from which effect gets loaded first i guess - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115857/#review50121 ----------------------------------------------------------- On Feb. 18, 2014, 12:52 a.m., Sebastian Kügler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115857/ > ----------------------------------------------------------- > > (Updated Feb. 18, 2014, 12:52 a.m.) > > > Review request for kwin and Plasma. > > > Repository: kde-workspace > > > Description > ------- > > Fix flickering of sliding popups while disappearing > > The last frame was fully painted for Plasma 2 panel popups, as it's > repainted in full on the last frame (without opacity and position > transformations applied). > > Removing the repaint on this last frame makes the popups disappear > smoothly for me, without other side-effects such as artifacts on the > screen or other repaint problems. > > > Diffs > ----- > > kwin/effects/slidingpopups/slidingpopups.cpp > fd697f0c62e9099d4be71e1f9d99e64ecb5ff663 > > Diff: https://git.reviewboard.kde.org/r/115857/diff/ > > > Testing > ------- > > Ran kwin with this on Intel driver, flickering is gone in Plasma 2 and > Yakuake 4.x. > > > Thanks, > > Sebastian Kügler > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
