Review Request 115857: Fix flickering of sliding popups while disappearing

[Marco Martin]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140218/19b881ed/attachment-0001.html>